Home
Help
Search
Login
Register
OPNsense Forum
»
English Forums
»
Virtual private networks
»
For those who still can't get OpenVPN NAT working for specific hosts
« previous
next »
Print
Pages: [
1
]
Author
Topic: For those who still can't get OpenVPN NAT working for specific hosts (Read 2025 times)
mlab
Newbie
Posts: 1
Karma: 0
For those who still can't get OpenVPN NAT working for specific hosts
«
on:
December 03, 2020, 02:49:32 am »
So I've been wrestling with Opnsense as a VPN client and then routing (using policy based routing) specific clients out via the VPN interface. The VPN tunnel was no issue, but any host trying to use it would never work. I tried using the logging feature to trace the path through the various LAN rules and NAT rules but didn't have much luck. I finally realized there was tpcdump that I could use in the console and I found something really strange (or at least to me). SYN and SYN ACK packets are being exchanged (from my internal host and the external host respectively) but the internal host never sends a ACK to establish connection. Looking at the tcpdump I realize that it appears the SYN ACK isn't making back to the internal host. For example, I'm testing against ifconfig.co (172.64.93.171). I see a SYN packet being sent from my internal host on interface em0 to ifconfig.co:
20:16:37.027920 IP mediasrv.mmhouse.local.59886 > 172.64.93.171.http: Flags
, seq 4263770428, win 64240, options [mss 1460,sackOK,TS val 361216859 ecr 0,nop,wscale 7], length 0
20:16:38.034005 IP mediasrv.mmhouse.local.59886 > 172.64.93.171.http: Flags , seq 4263770428, win 64240, options [mss 1460,sackOK,TS val 361217865 ecr 0,nop,wscale 7], length 0
20:16:40.050143 IP mediasrv.mmhouse.local.59886 > 172.64.93.171.http: Flags , seq 4263770428, win 64240, options [mss 1460,sackOK,TS val 361219881 ecr 0,nop,wscale 7], length 0
And coming back in via my VPN client interface ovpnc1:
20:16:37.044139 IP 172.64.93.171.http > mediasrv.mmhouse.local.59886: Flags [S.], seq 3186993400, ack 4263770429, win 65535, options [mss 1325,sackOK,TS val 949150398 ecr 361216859,nop,wscale 9], length 0
20:16:38.056913 IP 172.64.93.171.http > mediasrv.mmhouse.local.59886: Flags [S.], seq 3186993400, ack 4263770429, win 65535, options [mss 1325,sackOK,TS val 949151411 ecr 361216859,nop,wscale 9], length 0
20:16:39.062145 IP 172.64.93.171.http > mediasrv.mmhouse.local.59886: Flags [S.], seq 3186993400, ack 4263770429, win 65535, options [mss 1325,sackOK,TS val 949152416 ecr 361216859,nop,wscale 9], length 0
20:16:40.064533 IP 172.64.93.171.http > mediasrv.mmhouse.local.59886: Flags [S.], seq 3186993400, ack 4263770429, win 65535, options [mss 1325,sackOK,TS val 949153419 ecr 361216859,nop,wscale 9], length 0
And thats' where it ends. My prompt will be stuck waiting at 'curl 172.64.93.171' until it times out. So I decided I would try tweaking my inbound rule on my VPN interface and selecting 'None' for the 'State Type', and voila!
Following that I get an established connection. The following is from my internal interface showing packets going back to my internal host, unlike above:
20:30:12.309333 IP mediasrv.mmhouse.local.60792 > 172.64.93.171.http: Flags , seq 3886197186, win 64240, options [mss 1460,sackOK,TS val 362032139 ecr 0,nop,wscale 7], length 0
20:30:12.322863 IP 172.64.93.171.http > mediasrv.mmhouse.local.60792: Flags [S.], seq 265089553, ack 3886197187, win 65535, options [mss 1325,sackOK,TS val 949965676 ecr 362032139,nop,wscale 9], length 0
20:30:12.323340 IP mediasrv.mmhouse.local.60792 > 172.64.93.171.http: Flags [.], ack 1, win 502, options [nop,nop,TS val 362032153 ecr 949965676], length 0
20:30:12.323611 IP mediasrv.mmhouse.local.60792 > 172.64.93.171.http: Flags [P.], seq 1:78, ack 1, win 502, options [nop,nop,TS val 362032153 ecr 949965676], length 77: HTTP: GET / HTTP/1.1
20:30:12.343863 IP 172.64.93.171.http > mediasrv.mmhouse.local.60792: Flags [.], ack 78, win 128, options [nop,nop,TS val 949965697 ecr 362032153], length 0
20:30:12.345356 IP 172.64.93.171.http > mediasrv.mmhouse.local.60792: Flags [P.], seq 1:585, ack 78, win 128, options [nop,nop,TS val 949965699 ecr 362032153], length 584: HTTP: HTTP/1.1 403 Forbidden
20:30:12.345782 IP mediasrv.mmhouse.local.60792 > 172.64.93.171.http: Flags [.], ack 585, win 501, options [nop,nop,TS val 362032176 ecr 949965699], length 0
20:30:12.345986 IP 172.64.93.171.http > mediasrv.mmhouse.local.60792: Flags [F.], seq 585, ack 78, win 128, options [nop,nop,TS val 949965699 ecr 362032153], length 0
20:30:12.346335 IP mediasrv.mmhouse.local.60792 > 172.64.93.171.http: Flags [F.], seq 78, ack 585, win 501, options [nop,nop,TS val 362032176 ecr 949965699], length 0
So.. looks like for whatever reason opnsense is not tracking the state correctly and assuming the inbound SYN ACK isn't valid and just dropping it. I will try and figure out what is going on here, now that I know the lan rules and outbound NATing is actually working.. but worst case I might have to treat VPN traffic in a stateless manner and use host side iptables/etc.
BTW this is with Opnsense 20.7.5 running as a VM with Proxmox.
Seems it's doing strikethrough in my text.. no idea why.
Logged
Gauss23
Hero Member
Posts: 766
Karma: 39
Re: For those who still can't get OpenVPN NAT working for specific hosts
«
Reply #1 on:
December 05, 2020, 04:13:43 pm »
Site2Site or Client2Server connection?
You can reach the server network from the client side?
Did you assign an interface to the ovpncX connection? And added a gateway with the server IP in System:Gateways:Single?
This should work without NAT and stuff. Just set the gateway on the firewall rules, where you want the traffic to go out through the VPN. If your client should leave the server side network into the internet, you'll need to add an outbound NAT rule on interface WAN with source the VPN network, destination any.
Logged
„The S in IoT stands for Security!“
Print
Pages: [
1
]
« previous
next »
OPNsense Forum
»
English Forums
»
Virtual private networks
»
For those who still can't get OpenVPN NAT working for specific hosts