Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVpn "inbound" NAT

    Scheduled Pinned Locked Moved NAT
    9 Posts 2 Posters 1.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      Weppa
      last edited by

      Hello everyone

      I have a virtual Pfsense firewall protecting boxes that are dual homed
      Let's say all ETH0's of the boxes are on LAN (192.68.0.0/16) , and all ETH1 are on OPT1 (10.31.0.0/16)

      I have OPenvpn clients connecting on the firewall. They receive the two network (push routes).

      all ETH1 don't have a default gateway
      Which means that when they receive traffic from the VPN, going in thru ETH1, answer goes back thru ETH0

      Actually this works (?), but of course that's no want i want.

      Is is possible to "inbound NAT" the traffic from openvpn clients to 10.31.0.0 so that traffic seems to have come thru 10.31.0.1 (firewall IP on that LAN)

      I've tried every combination possible of NAT rules but it never works
      I tried adding the rule on WAN, on OPT1, on openVPN, with source IP : openvpn client network, and destination IP in OPT1, and the traffic is never NATTED

      Any help appreciated :)

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Easy. Connect to those hosts using the address on the subnet that has the default gateway back to pfSense.

        But to do what you want you want an outbound NAT entry on OPT1 translating the traffic sourced from the OpenVPN clients to a NAT address of 10.31.0.1.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • W
          Weppa
          last edited by

          Hi and thanks for helping me,

          I can assure you I tried every combination on earth of such NAT rules, and they never work :(

          DO I need to reload openvpn maybe ?
          My NAT rules are simply discarded…

          The only thing I havent tried yet is to reboot the firewall, I'm really going mad :(

          1 Reply Last reply Reply Quote 0
          • W
            Weppa
            last edited by

            Okay it's even weirder than I thought (and might well be a bug in pfsense)

            Actually this openvpn client receives his ip thru a specific override (but it's just a static IP in the openvpn range !)

            All other openvpn clients , in the same range, are indeed NATTed (simple NAT rule on OPT1 = sourc = openvpn clients, destination = OPT1 network, translated as interface IP)

            Only that specific client, who gets his IP from an override, completely bypasses the NAT process

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              Outbound NAT doesn't care or need to know whether this is a static address, OpenVPN, IPSec, etc. All it sees is the source IP address.

              If it didn't work you did it wrong. Post screenshots.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                @Weppa:

                (and might well be a bug in pfsense)

                Damn that's annoying.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • W
                  Weppa
                  last edited by

                  Okay I shouldn't have jumped to the "bug" thing. Let's forget about it. But please also admit that you know absolutely nothing about my background and you shouldn't always see a 4-posts-user as a newbie. I'll skip the CV.

                  My NAT rules are OK.

                  Traffic from "overriden" openvpn client 172.16.0.255 (fixed IP for his CN) is not NATED
                  Traffic from non overriden openvpn clients (in the same 172.16.0.0/25) range is NATTED

                  I'd be happy to provide screenshots so that we can dig into this a bit deeper (I may have done something wrong), but the fact remains that currently, with a proper NAT rule, I've got traffic MATCHING the nat rule that is not NATTED. There's zero confustion here ; tcpdump doesn't lie.

                  But I first have to "anonymize" the infrastructure as bit, as this is a live env.

                  Please don't get me wrong, I'd be glad to dig into this even if I found a workaround.

                  1 Reply Last reply Reply Quote 0
                  • W
                    Weppa
                    last edited by

                    Rebooting the firewall (the last things I did not do) solves the problem…

                    If anyone want to reproduce, feel free : I imagine this set up should suffice (no need to be dual homed)

                    connected Openvpn client ping something on a LAN, add a NAT rule matching this traffic to NAT it to exit interface's IP -> nothing happens. traffic that should be matched is simply not matched.
                    I'm not sure of the client has to be overriden or not (i'll try)

                    Until "something" happens ( state table ? ) that makes it finally work.

                    I'll try to do it on a VM on my mac.

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      Traffic from "overriden" openvpn client 172.16.0.255 (fixed IP for his CN) is not NATED
                      Traffic from non overriden openvpn clients (in the same 172.16.0.0/25) range is NATTED

                      Right there you call 172.16.0.0/25 the SAME RANGE as 172.16.0.255, which it, of course, is not. And 172.16.0.255 is not a valid IP address for /24 either. So what's the deal?

                      This is why we want screenshots.  We're dealing with RFC1918 addresses. There is practically zero reason to anonymize anything.

                      I never have to reboot any pfSenses to make things like this work. If I did it would be nearly worthless to me.

                      Do you have any packages or limiters configured?

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.