Hi everyone!
I need help with strange situation. There is a host (12.2) with jails, one of these jails is a vpn server (mpd5) with internal eth1=192.168.1.9 and another one is a mail server with internal eth1=192.168.1.4. The vpn jail is a vnet jail, and the mail jail is a simple jail.
Win-client (win10 or win7) is establishing pptp connection to vpn jail and obtaining ip 192.168.0.130. To give the client access to internal network I run on host “route add 192.168.0.0/24 192.168.1.9”, and at this stage all is fine, on the client side UDP (ping 192.168.1.4) and TCP (curl 192.168.1.4) protocols work without any problem.
Then I enable ipfw nat for vpn-client traffic on vpn jail (just modeling situation with nat to WAN for such clients because web conferences work badly through Squid):
This ipfw nat configuration is a proven variant, similar configuration gives jails access to WAN at host firewall. And from this moment TCP protocol on client side becomes non-working although UDP protocol stays fine. ICMP traffic between client (192.168.0.130) and mail server (192.168.1.4) is passing in both directions but when I run on client machine “curl 192.168.1.4” – I doesn’t receive any reply from 192.168.1.4 although tcpdump on vpn server’s interfaces shows that corresponding reply tcp-packets are passing right to the client.
I suppose that for some reason pptp-tunnel (by the way, the same situation with L2TP/IPSEC ) on client side does not accept incoming tcp-packets after ipfw nat has been “digging” into them. I would be grateful for any help in solving this problem except for variant with replacement ipfw with pf.
I need help with strange situation. There is a host (12.2) with jails, one of these jails is a vpn server (mpd5) with internal eth1=192.168.1.9 and another one is a mail server with internal eth1=192.168.1.4. The vpn jail is a vnet jail, and the mail jail is a simple jail.
Win-client (win10 or win7) is establishing pptp connection to vpn jail and obtaining ip 192.168.0.130. To give the client access to internal network I run on host “route add 192.168.0.0/24 192.168.1.9”, and at this stage all is fine, on the client side UDP (ping 192.168.1.4) and TCP (curl 192.168.1.4) protocols work without any problem.
Then I enable ipfw nat for vpn-client traffic on vpn jail (just modeling situation with nat to WAN for such clients because web conferences work badly through Squid):
Code:
ipfw -q nat 1 config if eth1 reset
#NAT for incoming traffic
ipfw -q add 00002 nat 1 ip4 from any to any in recv eth1
#loopback
ipfw add 00290 allow ip from any to any via lo0
#NAT for outgoing traffic
ipfw -q add 00800 nat 1 ip4 from any to any out xmit eth1
#open all
ipfw add 00900 allow ip from any to any
This ipfw nat configuration is a proven variant, similar configuration gives jails access to WAN at host firewall. And from this moment TCP protocol on client side becomes non-working although UDP protocol stays fine. ICMP traffic between client (192.168.0.130) and mail server (192.168.1.4) is passing in both directions but when I run on client machine “curl 192.168.1.4” – I doesn’t receive any reply from 192.168.1.4 although tcpdump on vpn server’s interfaces shows that corresponding reply tcp-packets are passing right to the client.
I suppose that for some reason pptp-tunnel (by the way, the same situation with L2TP/IPSEC ) on client side does not accept incoming tcp-packets after ipfw nat has been “digging” into them. I would be grateful for any help in solving this problem except for variant with replacement ipfw with pf.