OpenVPN with NAT on pfsense not working, same test but from a local linux machine behind pfsense, works.
-
Hi pfsense community, I would *like to request some help.
Problem description:
Linux plex server not reachable through VPN. I'm in a double nat scenario unfortunately.When the VPN is configured in the pfsense using openvpn tab, with port forward configured, the packets reach my server, but it nevers complete the 3 way handshake.
The same connection works, if I connect directly to the VPN through this same Linux plex server.Tests realized during the collection of the pcap files.
Tool used: https://www.yougetsignal.com/tools/open-ports/Test 1 - pfsense connecting directly to the vpn server, packets reach my Linux Plex server and the problem happens as we can see in the pcap. Port shows closed during test. (pcap name: pfsense_portforward.pcapng).
Obs: In this test the port forwarded was 32413.
pfsense_portforward.pcapngTest 2 - Linux plex server connected directly to the VPN behind pfsense, port shows open. (pcap name: linux_portforward.pcapng)
Obs: In this test the port forwarded was 40731.
linux_portforward.pcapngNotes about current configuration of psense during the problem:
- NAT outbound dynamic for the Linux Plex server through the VPN gateway:
(Linux plex server) to (any) use (VPN gateway). - Port forward:
(Port provided by the VPN provider) to (Linux plex server).
-Firewall rule: - VPN gateway set in the firewall rule, confirmed that the exit IP is the VPN provider.
In case you need further details, or tests, just let me know.
- NAT outbound dynamic for the Linux Plex server through the VPN gateway:
-
Maybe this will help: tcpdump on the plex server when the pfsense is connected to PIA.
tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), capture size 262144 bytes 22:50:33.157621 IP (tos 0x0, ttl 54, id 17275, offset 0, flags [DF], proto TCP (6), length 60) 198.199.98.246.59979 > 192.168.255.250.32413: Flags [S], cksum 0x4b44 (correct), seq 2629869958, win 14600, options [mss 1352,sackOK,TS val 1334829821 ecr 0,nop,wscale 8], length 0 22:50:33.157675 IP (tos 0x20, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.255.250.32413 > 198.199.98.246.59979: Flags [S.], cksum 0xea8f (incorrect -> 0xb19f), seq 3077031131, ack 2629869959, win 65160, options [mss 1460,sackOK,TS val 1784474887 ecr 1334829821,nop,wscale 7], length 0 22:50:34.157654 IP (tos 0x0, ttl 54, id 17276, offset 0, flags [DF], proto TCP (6), length 60) 198.199.98.246.59979 > 192.168.255.250.32413: Flags [S], cksum 0x4a4a (correct), seq 2629869958, win 14600, options [mss 1352,sackOK,TS val 1334830071 ecr 0,nop,wscale 8], length 0 22:50:34.157699 IP (tos 0x20, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.255.250.32413 > 198.199.98.246.59979: Flags [S.], cksum 0xea8f (incorrect -> 0xadb7), seq 3077031131, ack 2629869959, win 65160, options [mss 1460,sackOK,TS val 1784475887 ecr 1334829821,nop,wscale 7], length 0 22:50:34.158582 IP (tos 0x0, ttl 54, id 12404, offset 0, flags [DF], proto TCP (6), length 60)
-
No one? :(
I can see my server replying with SYN ACK to pfsense, and pfsense doesn't send it out through openvpn interface, no log whatsoever about what could be happening with this packet.
Almost quitting this idea and setting the vpn client directly into my server, which I really didn't want to.
tcpdump in openvpn interface:
[2.4.4-RELEASE][root@pfSense.local.lan]/root: tcpdump -i ovpnc1 port 46521 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ovpnc1, link-type NULL (BSD loopback), capture size 262144 bytes 19:58:39.540573 IP 198.199.98.246.39332 > 10.35.10.6.46521: Flags [S], seq 1252813190, win 14600, options [mss 1352,sackOK,TS val 1353851704 ecr 0,nop,wscale 8], length 0 19:58:40.537837 IP 198.199.98.246.39332 > 10.35.10.6.46521: Flags [S], seq 1252813190, win 14600, options [mss 1352,sackOK,TS val 1353851954 ecr 0,nop,wscale 8], length 0 19:58:40.553378 IP 198.199.98.246.39334 > 10.35.10.6.46521: Flags [S], seq 2924475473, win 14600, options [mss 1352,sackOK,TS val 1353851955 ecr 0,nop,wscale 8], length 0 19:58:41.546834 IP 198.199.98.246.39336 > 10.35.10.6.46521: Flags [S], seq 2733758528, win 14600, options [mss 1352,sackOK,TS val 1353852205 ecr 0,nop,wscale 8], length 0 19:58:41.553934 IP 198.199.98.246.39334 > 10.35.10.6.46521: Flags [S], seq 2924475473, win 14600, options [mss 1352,sackOK,TS val 1353852205 ecr 0,nop,wscale 8], length 0 19:58:42.547809 IP 198.199.98.246.39336 > 10.35.10.6.46521: Flags [S], seq 2733758528, win 14600, options [mss 1352,sackOK,TS val 1353852455 ecr 0,nop,wscale 8], length 0
Another try, but now capture on the LAN interface.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on mvneta1.100, link-type EN10MB (Ethernet), capture size 262144 bytes 19:59:38.630343 IP 198.199.98.246.39442 > 192.168.255.250.46521: Flags [S], seq 3286002739, win 14600, options [mss 1352,sackOK,TS val 1353866477 ecr 0,nop,wscale 8], length 0 19:59:38.630617 IP 192.168.255.250.46521 > 198.199.98.246.39442: Flags [S.], seq 1022654507, ack 3286002740, win 65160, options [mss 1460,sackOK,TS val 2015527149 ecr 1353866477,nop,wscale 7], length 0 19:59:39.629009 IP 198.199.98.246.39442 > 192.168.255.250.46521: Flags [S], seq 3286002739, win 14600, options [mss 1352,sackOK,TS val 1353866727 ecr 0,nop,wscale 8], length 0 19:59:39.629288 IP 192.168.255.250.46521 > 198.199.98.246.39442: Flags [S.], seq 1022654507, ack 3286002740, win 65160, options [mss 1460,sackOK,TS val 2015528148 ecr 1353866477,nop,wscale 7], length 0 19:59:39.639499 IP 198.199.98.246.39444 > 192.168.255.250.46521: Flags [S], seq 2922434547, win 14600, options [mss 1352,sackOK,TS val 1353866727 ecr 0,nop,wscale 8], length 0 19:59:39.639748 IP 192.168.255.250.46521 > 198.199.98.246.39444: Flags [S.], seq 114002427, ack 2922434548, win 65160, options [mss 1460,sackOK,TS val 2015528158 ecr 1353866727,nop,wscale 7], length 0 19:59:40.635311 IP 192.168.255.250.46521 > 198.199.98.246.39442: Flags [S.], seq 1022654507, ack 3286002740, win 65160, options [mss 1460,sackOK,TS val 2015529154 ecr 1353866477,nop,wscale 7], length 0 19:59:40.636941 IP 198.199.98.246.39444 > 192.168.255.250.46521: Flags [S], seq 2922434547, win 14600, options [mss 1352,sackOK,TS val 1353866977 ecr 0,nop,wscale 8], length 0 19:59:40.637171 IP 192.168.255.250.46521 > 198.199.98.246.39444: Flags [S.], seq 114002427, ack 2922434548, win 65160, options [mss 1460,sackOK,TS val 2015529156 ecr 1353866727,nop,wscale 7], length 0
-
GOT IT!! :)
https://forum.netgate.com/topic/114903/routing-internet-traffic-between-a-remote-openvpn-server-and-pfsense/2
Just had to remove the firewall rules from the openvpn tab.
Read that post, noticed some hits in the Openvpn tab (allow all that was there by default), removed, and it worked.
Now, rules only created in the openvpn interface created for the client. -
@mcury You beat me to it! I was just about to tell you to make sure the rules on your OpenVPN tab are explicit so traffic doesn't get matched on the wrong interface.
-
@marvosa Thanks man, it wasn't easy, almost gave up.
That was kind of my last attempt... opened a beer to celebrate lol