Route traffic through a pfSense VM running an OpenVPN server behind NAT



  • Hello,

    I have almost absolute zero knowledge on pfSense / network configuration and was hoping that someone could help me clarify if this is possible to do and how to?

    • I am trying to route all internet traffic using OpenVPN from my laptop/phone when I'm away from home through my home network's pfSense machine and accessing the internet through there.

    Setup at home:

    • My pfSense is running on a virtual machine behind the ISP's router, in what appears to be a double NAT situation: ISP router (192.168.1.0/24) –> pfSense VM (192.168.1.201 WAN / 192.168.2.1 LAN)
    • I configured the ISP router to forward UDP port 1194 to 192.168.1.201.
    • I set up on pfSense a dynamic dns service which is running properly, eg.: mylab.ddns.net

    I'm not sure if I need to forward or setup anything else on the ISP's router or leave it like that.
    Next comes the pfSense configuration but I'm blown out with the amount of options.
    I tried following a tutorial on youtube (https://youtu.be/xiy52Hn5bTc), generating the certificates, going through the openvpn wizard and exporting the config to my mobile. But I couldn't access from an outside connection to the OpenVPN server on pfSense.

    If I try to connect with an OpenVPN client inside the 192.168.1.0/24 network it works to the point of being able to ping the machines on 192.168.2.0/24. But it doesn't access the internet.
    From outside, the OpenVPN client resolves the dynamic ip correctly, but stays 'waiting for server answer' forever. I don't see anything appearing on the firewall log either.

    I hope someone can help me with this, probably it's a simple thing to solve, or maybe even an impossible thing given the fact pfsense sits behind another router's nat. I don't know, kind of lost with this really after so many hours trying.

    Kind regards



  • No, your project is not impossible.

    But first of all, why do you let pfSense handle the DDNS updates?? The updates should be handled on the ISP router, this is the only device which take notice that the IP has changed.

    In case of the VPN issue, check the outbound NAT rules and post a screenshot. A miss-configured outbound NAT could be the reason for your issues.

    Also since you have a WAN and a LAN network on pfSense, you can check if you have internet at LAN machines, when the upstream traffic is routed over pfSense.



  • Hello viragomann, first of all thank you so much for the quick reply!

    But first of all, why do you let pfSense handle the DDNS updates?? The updates should be handled on the ISP router, this is the only device which take notice that the IP has changed.

    At first I had the ISP router taking care of that. But that router lacks proper configuration options and I found someone on the forums saying that even behind the NAT the pfsense could perfectly run the DDNS updates and indeed it does. It checks periodically and updates with the correct external IP. So I guess both options were fine but I would prefer to configure everything I can on pfsense and leave the ISP router as untouched as possible.

    Also since you have a WAN and a LAN network on pfSense, you can check if you have internet at LAN machines, when the upstream traffic is routed over pfSense.

    All machines connected to the LAN side of pfsense are with good connectivity, can reach each other and have internet.

    If I try to connect to the OpenVPN server with a device on the 192.168.1.0/24 using the external IP, it connects. Computer X (192.168.1.100) –> External IP (85.127.128.50) --> Connects successfully and gets an ip on vpn subnet 192.168.3.0/24. Can also ping other computers and browse internet.
    If I try to connect to the same OpenVPN server, with the same device, but from outside the network, it doesn't. Computer C (some random ip from ISP) --> External IP (85.127.128.50). Waiting for server..

    I've drawn up a diagram of the simple network I'm trying to setup, and did the screenshots you asked. Hope they're useful to sort out the problem.

    Kind regards and once again thank you for your help.












  • The settings seem to be okay.

    Maybe pfSense doesn't get the VPN packets forwarded to its WAN address. Check this by doing a packet capture on the WAN interface filterung UDP 1194.



  • I did what you suggested and these are the results.

    Accessing from inside with 192.168.1.100/24 to the external ip 85.127.128.50, connection successful, and lots of entries in the packet capture between the pfsense ip and the external. In this case its a bit confusing because the outgoing external address would be the same as the incoming target external address:

    18:13:48.567653 BC:85:A6:59:01:B8 > 61:83:73:97:B1:CB, ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 63, id 11941, offset 0, flags [DF], proto UDP (17), length 82)
        85.127.128.50.42099 > 192.168.1.201.1194: [udp sum ok] UDP, length 54
    18:13:48.568928 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 108: (tos 0x0, ttl 64, id 45910, offset 0, flags [none], proto UDP (17), length 94)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 66
    18:13:48.572191 BC:85:A6:59:01:B8 > 61:83:73:97:B1:CB, ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 63, id 11943, offset 0, flags [DF], proto UDP (17), length 90)
        85.127.128.50.42099 > 192.168.1.201.1194: [udp sum ok] UDP, length 62
    18:13:48.572199 BC:85:A6:59:01:B8 > 61:83:73:97:B1:CB, ethertype IPv4 (0x0800), length 260: (tos 0x0, ttl 63, id 11944, offset 0, flags [DF], proto UDP (17), length 246)
        85.127.128.50.42099 > 192.168.1.201.1194: [udp sum ok] UDP, length 218
    18:13:48.586382 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 1202: (tos 0x0, ttl 64, id 41839, offset 0, flags [none], proto UDP (17), length 1188)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 1160
    18:13:48.586456 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 1190: (tos 0x0, ttl 64, id 45829, offset 0, flags [none], proto UDP (17), length 1176)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 1148
    18:13:48.586519 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 1190: (tos 0x0, ttl 64, id 35977, offset 0, flags [none], proto UDP (17), length 1176)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 1148
    18:13:48.586579 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 260: (tos 0x0, ttl 64, id 26848, offset 0, flags [none], proto UDP (17), length 246)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 218
    18:13:48.638837 BC:85:A6:59:01:B8 > 61:83:73:97:B1:CB, ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 63, id 11945, offset 0, flags [DF], proto UDP (17), length 90)
        85.127.128.50.42099 > 192.168.1.201.1194: [udp sum ok] UDP, length 62
    18:13:48.640483 BC:85:A6:59:01:B8 > 61:83:73:97:B1:CB, ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 63, id 11946, offset 0, flags [DF], proto UDP (17), length 90)
        85.127.128.50.42099 > 192.168.1.201.1194: [udp sum ok] UDP, length 62
    ...
    

    Accessing from outside the network to the same external ip, connection doesn't get through BUT the packet capture appears to show some sort of begginning of negotiation only in one direction:

    18:14:51.892863 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 123: (tos 0x0, ttl 64, id 57831, offset 0, flags [none], proto UDP (17 ), length 109)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 81
    18:14:54.347628 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 187: (tos 0x0, ttl 64, id 52252, offset 0, flags [none], proto UDP (17), length 173)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 145
    18:15:04.947953 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 123: (tos 0x0, ttl 64, id 61688, offset 0, flags [none], proto UDP (17), length 109)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 81
    18:15:14.270929 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 123: (tos 0x0, ttl 64, id 14780, offset 0, flags [none], proto UDP (17), length 109)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 81
    18:15:24.323321 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 123: (tos 0x0, ttl 64, id 46258, offset 0, flags [none], proto UDP (17), length 109)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 81
    18:15:34.428274 61:83:73:97:B1:CB > BC:85:A6:59:01:B8, ethertype IPv4 (0x0800), length 123: (tos 0x0, ttl 64, id 5835, offset 0, flags [none], proto UDP (17), length 109)
        192.168.1.201.1194 > 85.127.128.50.42099: [udp sum ok] UDP, length 81
    
    


  • It seems that there is something messed up in your ISP router. It translates the source address of incoming packets to its WAN address??  :o
    That's not a normal behavior. Some routers may translate all incoming traffic source to their LAN address, but WAN?

    Also very strange or a great accident is the exactly same source port of both connections.

    In the capture from the external connection attempt you can see the response packets from pfSense sent out to the WAN address. But obviously the router doesn't forward them.


Log in to reply