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

    Strange routing problem from OpenVPN clients to IPsec remote site

    IPsec
    4
    11
    2.7k
    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.
    • L
      luke404
      last edited by

      We have a pfSense-2.1.5 box with a local LAN, a single WAN, and an IPsec tunnel to a remote site.
      This setup is working correctly but we were not able to let it work with pfSense-2.2.1 no matter what we tried, so we had to settle on 2.1.x. We don't have any control over the remote endpoint, I only know it is a Microtik router.

      Now we have a need to allow people access to the local LAN and the remote site, all through pfSense.

      I configured an OpenVPN server on pfSense and traffic between OpenVPN clients and the local LAN is working correctly, but I am failing at letting OpenVPN clients talk with hosts on the remote lan.

      The remote site of course doesn't know anything about the OpenVPN subnet, the IPSec tunnel will only accept and route traffic from the local LAN subnet, so I added a NAT rule for that.

      Some details:

      • pfSense LAN is 10.10.10.0/24, pfSense is 10.10.10.1
      • remote lan is 192.168.10.0/24
      • OpenVPN IPv4 tunnel network is 192.168.254.0/24
      • IPsec phase two is configured for "local subnet = LAN" and "remote subnet = 192.168.10.0/24"
      • in Firewall > NAT > Outbound we switched from "Automatic outbound NAT" to "Manual outbound NAT"
      • we added an host alias "LAN_ip" for host 10.10.10.1
      • we added a nat rule: interface IPsec, source 192.168.254.0/24 (the openvpn guests), destination 192.168.10.0/24 (the remote site), NAT address "LAN_ip" (the pfSense LAN ip address)

      If I try to ping a remote host from pfSense itself or from an host of the local LAN, it works and I can see echo requests and replies on the IPsec interface with "tcpdump -n -i enc0".

      If I try to ping a remote host from an OpenVPN client, it does not work. I can see echo requests with "tcpdump -n -i ovpns1", so I know the OpenVPN client is correctly routing traffic to pfSense.

      But on the pfSense box I can see, using tcpdump, these echo requests showing up on em1 (the WAN interface) and not on enc0 (the IPsec interface).

      It seems to me that traffic coming in through OpenVPN for 192.168.10.0/24 is not getting correctly routed to the IPsec link and ends up using the default gateway on the wan link.

      Any help or suggestion would be gladly accepted, thanks.

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

        I believe you need another phase 2 entry for 192.168.254.0/24 <==> 192.168.10.0/24.  This is easy between two pfSenses.  I have no idea about the microtik.

        Otherwise I believe you have to NAT your OpenVPN connections to something on 10.10.10.0/24 for traffic destined for 192.168.10.0/24.  I am not sure if that's even possible since that's usually done outbound and you can't NAT on pfSense IPSec "interfaces."

        In the diagram linked below, you want the Remote Access clients to be able to connect to pfSense C LAN (really microtik LAN)?  What about connections originating on pfSense C LAN?  Do they need to be able to open connections/states in the other direction?

        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
        • L
          luke404
          last edited by

          @Derelict:

          I believe you need another phase 2 entry for 192.168.254.0/24 <==> 192.168.10.0/24.  This is easy between two pfSenses.  I have no idea about the microtik.

          No, the remote site does not know anything about the 192.168.254.0/24 subnet and cannot route anything to it. Packets from that network are allowed only on our local lan, any other destination would need them to be NATted.

          @Derelict:

          Otherwise I believe you have to NAT your OpenVPN connections to something on 10.10.10.0/24 for traffic destined for 192.168.10.0/24.  I am not sure if that's even possible since that's usually done outbound and you can't NAT on pfSense IPSec "interfaces."

          And that's exactly what I was trying to do, I thought it would NAT outbound on IPSec interfaces, that's even hinted in the docs.
          I did try something with the "Local Network" fields in IPSec Phase2 without success, maybe I got something wrong there…

          @Derelict:

          In the diagram linked below, you want the Remote Access clients to be able to connect to pfSense C LAN (really microtik LAN)?  What about connections originating on pfSense C LAN?  Do they need to be able to open connections/states in the other direction?

          Yes, I want OpenVPN Remote Access clients to be able to access the remote lan (microtik LAN in my case).
          No, hosts on the microtik LAN will not spawn new connections to OpenVPN clients, only on our local LAN (pfSense A LAN in your diagram) and that's already working right now.

          thank you

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

            It looks like I got this working.  I just need to verify what needs to be done for a Phase 2 for the NAT from the OpenVPN remote access in addition to a Phase 2 for pfSense A LAN to pfSense C LAN.

            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

              Yeah.  Not quite sure what's up with this yet.  I can get the OpenVPN Remote Access to NAT using 172.26.0.200 and access 172.28.4.100 but as soon as I add another Phase 2 for 172.26.0.0/24 <==> 172.28.4.0/24 pfSense A starts sending the previously-working NAT traffic out the default gateway instead.  Not sure if you can do both.  Hopefully someone chimes in.

              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
              • L
                luke404
                last edited by

                …and I should mention we actually have a lot of Phase2's for many different remote LANs, all on the same Phase1  :-\

                1 Reply Last reply Reply Quote 1
                • E
                  eri--
                  last edited by

                  Can you try a snapshot from snapshots.pfsense.org and see if that fixes the issues with multiple P2 on a P1?

                  1 Reply Last reply Reply Quote 0
                  • L
                    luke404
                    last edited by

                    @ermal:

                    Can you try a snapshot from snapshots.pfsense.org and see if that fixes the issues with multiple P2 on a P1?

                    As far as I can see those snapshots are only of pfSense-2.2.2 and we weren't able to succesfully set up the IPsec part (even with just one Phase2) with the remote Microtik when we tried 2.2.0 and 2.2.1. Now the system is in production and I can't bring it down, I will try to set up a parallel test with a second pfSense to that same Microtik but I guess it'll take a few weeks before we can do that :/

                    1 Reply Last reply Reply Quote 1
                    • K
                      kapara
                      last edited by

                      Did you ever get this resolved?

                      Skype ID:  Marinhd

                      1 Reply Last reply Reply Quote 0
                      • L
                        luke404
                        last edited by

                        We had to work around the issue in very little time so we just set up a second pfSense on the same LAN. The main one does everything except OpenVPN and the second one does just OpenVPN, so no problems in routing OpenVPN to/from IPSec on a single box. I hadn't had any other opportunity so far to re-test that kind of setup with a single pfSense system.

                        1 Reply Last reply Reply Quote 1
                        • L
                          luke404
                          last edited by

                          I'm resurrecting this old thread because we've stumbled upon an identical situation (i.e. we need to NAT traffic from OpenVPN clients directed to a remote IPSec network).

                          As far as I can tell nothing has changed up to and including pfSense 2.4.x: can anyone confirm that it still is not possible in any way to NAT traffic coming in from OpenVPN clients with destination on a remote IPSec network?

                          (please do note that I cannot add another IPSec P2 to IPSec for the OpenVPN subnet)

                          thank you all.

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