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

[Solved] OpenVPN NAT Outbound

Scheduled Pinned Locked Moved OpenVPN
15 Posts 2 Posters 6.7k 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.
  • F
    fab1330
    last edited by Nov 12, 2014, 10:42 PM Nov 9, 2014, 12:29 AM

    Hello,

    I would like to set up an OpenVPN Site-to-Site link.

    The problem is that the router B does not know the OpenVPN 10.100.0.0/24 network. And I can not add a static route in this router.

    I see only one solution: use NAT to translate OpenVPN IP address into pfSense B interfaces ip address

    Is this possible? I did not succeed with Outbound NAT

    Thanks for your help :-)

    1 Reply Last reply Reply Quote 0
    • P
      phil.davis
      last edited by Nov 9, 2014, 1:00 PM

      You probably do not care much about 10.100.0.0/24 - RouterB will never really care to talk to that anyway.
      But you do care about pfSenseA LAN 10.30.0.0/24, and I guess you are policy-routing some/most/all its outbound traffic across the OpenVPN to pfSenseB.
      I did this somewhere, and from memory and thinking about it, you need to add an outbound NAT rule on SiteB LAN of pfSenseB that says to NAT traffic from pfSenseA LAN subnet 10.30.0.0/24 destination !SiteB LAN - then traffic from pfSenseA LAN will appear to come from pfSenseB LAN IP and RouterB will be happy to work with it.
      I put the "!SiteB LAN" bit there, because you might not want to hide pfSenseA LAN device IPs from pfSenseB LAN in general.

      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

      1 Reply Last reply Reply Quote 0
      • F
        fab1330
        last edited by Nov 9, 2014, 2:46 PM

        @phil.davis:

        You probably do not care much about 10.100.0.0/24 - RouterB will never really care to talk to that anyway.
        But you do care about pfSenseA LAN 10.30.0.0/24, and I guess you are policy-routing some/most/all its outbound traffic across the OpenVPN to pfSenseB.
        I did this somewhere, and from memory and thinking about it, you need to add an outbound NAT rule on SiteB LAN of pfSenseB that says to NAT traffic from pfSenseA LAN subnet 10.30.0.0/24 destination !SiteB LAN - then traffic from pfSenseA LAN will appear to come from pfSenseB LAN IP and RouterB will be happy to work with it.
        I put the "!SiteB LAN" bit there, because you might not want to hide pfSenseA LAN device IPs from pfSenseB LAN in general.

        In addition to functioning in the site-to-site, it must also work in road-warrior.
        In road-warrior mode, my device get an IP in the network 10.100.0.0/24.
        And I have the same problem. B networks that have as default gateway router B does not know the network 10.100.0.0/24.
        Here's what I tried as Outbound NAT in pfSense B :

        without success :-(

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by Nov 9, 2014, 4:45 PM

          Here's what I tried as Outbound NAT in pfSense B :
          without success :-(

          The picture was also without success  ;) - try posting again.
          You should be able to also put manual NAT on pfSenseB LAN for the OpenVPN subnet.
          Personally I would have a dedicated client-server pair for the site-to-site link, then make a road-warrior server also. That allows you to reconfigure/restart one server without interrupting the other. I can't immediately think of other reasons why.
          In any case, the NAT out onto pfSenseB LAN should do the trick for both.

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • F
            fab1330
            last edited by Nov 9, 2014, 6:10 PM

            @phil.davis:

            Here's what I tried as Outbound NAT in pfSense B :
            without success :-(

            The picture was also without success  ;) - try posting again.
            You should be able to also put manual NAT on pfSenseB LAN for the OpenVPN subnet.
            Personally I would have a dedicated client-server pair for the site-to-site link, then make a road-warrior server also. That allows you to reconfigure/restart one server without interrupting the other. I can't immediately think of other reasons why.
            In any case, the NAT out onto pfSenseB LAN should do the trick for both.

            Oops, here's what I tried.
            But without success

            1 Reply Last reply Reply Quote 0
            • P
              phil.davis
              last edited by Nov 10, 2014, 4:38 AM

              Your picture is now successful in both places.
              Destination should be "*" - you want general traffic heading to the internet in general to get NAT applied on the way out of pfSenseB towards routerB.
              And that should be on the interface on pfSenseB that heads towards routerB.
              I expect you also want a similar NAT rule for source 10.30.0.0/24 (traffic from pfSenseA LAN)

              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

              1 Reply Last reply Reply Quote 0
              • F
                fab1330
                last edited by Nov 10, 2014, 10:21 AM

                @phil.davis:

                Destination should be "*" - you want general traffic heading to the internet in general to get NAT applied on the way out of pfSenseB towards routerB.
                And that should be on the interface on pfSenseB that heads towards routerB.
                I expect you also want a similar NAT rule for source 10.30.0.0/24 (traffic from pfSenseA LAN)

                Like this?

                It doesn't work;-(

                1 Reply Last reply Reply Quote 0
                • P
                  phil.davis
                  last edited by Nov 11, 2014, 2:14 AM

                  Why does the interface column say VPN_UDP?
                  I am expecting it to be the interface for pfSenseB eth0 (maybe called LAN or LAN1 or something), which is where the packets are exiting and need to have NAT applied.
                  Then the NAT address can be LANaddress or similar, rather than entering an actual IP address.

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                  1 Reply Last reply Reply Quote 0
                  • F
                    fab1330
                    last edited by Nov 11, 2014, 1:19 PM

                    @phil.davis:

                    Why does the interface column say VPN_UDP?
                    I am expecting it to be the interface for pfSenseB eth0 (maybe called LAN or LAN1 or something), which is where the packets are exiting and need to have NAT applied.
                    Then the NAT address can be LANaddress or similar, rather than entering an actual IP address.

                    I also tried doing a NAT on output inteface. example eth0 on pfSense B, but it does not work.

                    And if I do a ping from 10.100.0.5 to 192.168.10.150, and I make a packet capture sur eth0 (BUREAUTIQUE), I do not see my ping request

                    1 Reply Last reply Reply Quote 0
                    • P
                      phil.davis
                      last edited by Nov 12, 2014, 1:26 AM

                      I think what you have done there on BUREAUTIQUE should work.
                      What firewall rules are on OpenVPN? Maybe the packet/s are bring blocked by the firewall?
                      Anyone see the problem here?

                      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                      1 Reply Last reply Reply Quote 0
                      • F
                        fab1330
                        last edited by Nov 12, 2014, 10:48 AM

                        @phil.davis:

                        What firewall rules are on OpenVPN? Maybe the packet/s are bring blocked by the firewall?

                        On all interfaces, I authorize any

                        I am surprised not to find other posts similar to my problem. There must be others who have NAT configured with OpenVPN

                        1 Reply Last reply Reply Quote 0
                        • P
                          phil.davis
                          last edited by Nov 12, 2014, 1:51 PM

                          I found an example of this on my network - I have a WiMax device at a remote siteB. It is not in bridge mode, it is an upstream hop from the pfSense there, but it does not know anything about my internal network. It sees all traffic NATed from pfSense as coming from "WIMAXaddress", its address itself is "WimaxGW".
                          INF_Subnets is an alias that contains all internal addresses across the various office networks that are all VPN'd together.
                          I have a rule on WIMAX interface to NAT traffic from all of INF_Subnets when it goes out WIMAX.
                          Right now I am VPN'd into siteA. I can ping and traceroute to the IP of WimaxGW - the traffic goes from my laptop, across road-warrior VPN to siteA, across another VPN to siteB, then is NATed out WIMAX interface using WIMAXaddress to WimaxGW. WimaxGW replies to WIMAXaddres fine, it is unNATed, and routed back across the 2 VPN links to me.
                          Your setup should work in a very similar way.
                          Do some traceroute from SiteA and packet capture to see where things get to a where they stop.

                          WiMax-NAT-rule.png
                          WiMax-NAT-rule.png_thumb

                          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                          1 Reply Last reply Reply Quote 0
                          • F
                            fab1330
                            last edited by Nov 12, 2014, 10:42 PM

                            @phil.davis:

                            I found an example of this on my network - I have a WiMax device at a remote siteB. It is not in bridge mode, it is an upstream hop from the pfSense there, but it does not know anything about my internal network. It sees all traffic NATed from pfSense as coming from "WIMAXaddress", its address itself is "WimaxGW".
                            INF_Subnets is an alias that contains all internal addresses across the various office networks that are all VPN'd together.
                            I have a rule on WIMAX interface to NAT traffic from all of INF_Subnets when it goes out WIMAX.
                            Right now I am VPN'd into siteA. I can ping and traceroute to the IP of WimaxGW - the traffic goes from my laptop, across road-warrior VPN to siteA, across another VPN to siteB, then is NATed out WIMAX interface using WIMAXaddress to WimaxGW. WimaxGW replies to WIMAXaddres fine, it is unNATed, and routed back across the 2 VPN links to me.
                            Your setup should work in a very similar way.
                            Do some traceroute from SiteA and packet capture to see where things get to a where they stop.

                            A big thank you for your help!

                            By dint of making test, by doing this, it works now :

                            Thanks again :)

                            Have a nice evening

                            1 Reply Last reply Reply Quote 0
                            • P
                              phil.davis
                              last edited by Nov 13, 2014, 6:29 AM

                              No problem. Yes, what you have done will definitely work! I guess the traffic across the VPN then going out of pfSenseB to routerB was going across VILLES or WINRADIO interface.
                              The wide NAT rules you have now will hide siteA LAN address from all devices at siteB - that might be good for conectivity, but if, for example, you want to log client connections to a server in siteB LAN, then all connections from siteA will apear to come from a pfSenseB interface IP.
                              It all depends on your requirements and whether you want to spend time narrowing down the rules to only the NAT that is essential!

                              As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                              If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                              1 Reply Last reply Reply Quote 0
                              • F
                                fab1330
                                last edited by Nov 13, 2014, 11:15 AM

                                Yes I could restrict more NAT rules, but I have many networks behind pfSense A, so I prefer all open here:–)

                                1 Reply Last reply Reply Quote 0
                                15 out of 15
                                • First post
                                  15/15
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                  This community forum collects and processes your personal information.
                                  consent.not_received