OpenVPN Support Forum

Hello All, i am new to this forum.

I come to you with a very weird situation.

I have setup a Community pfsense in an AWS instance, everything WAS working just fine until recently.

Some Data:
Pfsense Community Version 2.6
OpenVPN Server on UPD 1194 at WAN address. (clients from 0.0.0.0/0 connects just fine)
Properly setup security groups and rules etc.
Pfsense has a LAN interface where our servers reside subnet 172.16.1.0/24
Pfsense has a WAn interface where clients connect with no issue.
Pfsense is the OVPN server at 10.11.12.1 to clients with ips 10.11.12.0/24.

So...

server subnet -> 172.16.1.0/24 -> to pfsense 172.16.1.10 (as their gateway, (not aws's gateway (172.16.1.1.) ) -> 10.11.12.0/24 subnet for openvpn clients (mostly win 10 laptops of people working in their homes)


VPN clients can reach our servers with no issue, icmp, udp works great, but with tcp i am seeing indications of Asymetric routing.
recently some vpn clients can't reach our servers from their home where they share the 192.168.1.0/24 network, the default subnet for many home network equipment.

from this failing clients i can reach tcp services like rdp, udp based services, and icmp works just fine. but services at 80, 443, 22, they just timeout.

i can see in the pfsense logs, the same output as out of state tcp connections, i have the logs for the firewall blocking their connection
even if they have pass rules for all ipv4 comming from their subbnet to the server subnet and the same in the return path.

Clients connecting from 192.168.1.0/24 subnet from their ISP router CAN'T connect to our internal servers,
however, not EVERY computer displays the same symptoms, my laptop can connect even if i am connected directly to the modem, and
my client ip is in 198.168.1.0/24, but some can't. Their attempts just timeouts, they can however use rdp, but no http, https, ssh, or any tcp based service...

howiver, those same clients works just fine when they are at our office subnet 198.168.150.0/24 they work just fine, seems this only happends when the tunnel is created from 192.168.1.0/24.

classic asymetric routing...
icmp not affected
udp not affected
tcp suffering from TCP/A, TCP/RA, TCP/SA ....

but why ?