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

    Routing between interfaces..

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 4 Posters 1.2k 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.
    • M
      MordyT
      last edited by

      Hello,
      Hoping someone can point me in the right direction.

      Have 2x pfSense boxes - and OpenVPN tunnel between them. On the server side I define what subnets to bring over the tunnel, and then on the remote side I define the same subnets. On the remote side, no matter what VLAN / Interface / subnet I am on, I am able to (firewall rules permitting) access resources from that tunnel. pfSense "Routes" that traffic as needed.

      I also have an IPSec tunnel connected. On the server side I define what subnets to bring over the tunnel, and then on the remote side I define the same subnets. When a PC on the remote side is on one of those subnets - traffic flows no issue. But if they are on a different subnet, traffic does not flow.

      How can I get pfSense to "route" that traffic over the tunnel?

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

        Please be more specific. I cannot picture what you are talking about.

        A diagram would be great. Complete with subnets, addresses, gateway addresses, etc.

        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
        • M
          MordyT
          last edited by MordyT

          See attached. Let me know if that helps or more info is needed.
          0_1529896667090_mylittlediagram.png

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

            Great. Please give a complete example of something that is not working.

            When host address X tries to connect to host address Y on port X this happens.

            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
            • M
              MordyT
              last edited by

              Hi,
              Sorry - I missed the notification this was responded to - didn't mean to ignore you for 5 days.
              Thank you again for your help so far.

              When I try to access 172.17.1.1 from 172.17.10.1 it works.
              When I try to access 172.17.1.1 from 192.168.3.12 it does not work.
              When I try to access 10.0.1.1 from 192.168.3.12 it work.

              Let me know if you need further information.
              Thanks

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

                Sounds like you need a phase 2 on the IPsec tunnel for traffic between 172.17.1.0/24 and 192.168.3.0/24

                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
                • 4
                  4ROMANY
                  last edited by

                  In a normal site to site VPN tunnel you have to specify what traffic you want to encrypt over that tunnel. Both VPN endpoints have to agree on that "interesting" traffic before packets will be accepted. The VPN endpoints also need to know (via routing normally) that that traffic needs to be routed via the tunnels. That how it would work in a typical Cisco environment - I would assume pfsense would be similar. Phase 2 is the part where the actual traffic gets encrypted....

                  1 Reply Last reply Reply Quote 0
                  • M
                    MordyT
                    last edited by

                    I forgot to follow up on this.

                    I can't make changes on the Cisco side, so I couldn't make a separate P2 from 172.17.1.0/24 to 192.168.3.0/24. I needed to nat traffic so that 192.168.3.0/24 routes through 172.17.10.0/24 (since the P2 already exists from that subnet)

                    I found this that seemed be what I was wanting to do.
                    https://serverfault.com/questions/703112/routing-between-pfsense-subnets-and-ipsec-vpn

                    I ended up making a second P2 only on the pfSense side with the local network being 192.168.3.0/24 and the NAT network being 172.17.10.0/24 and the remote network being 72.17.1.0/24.

                    Before:
                    0_1538874838366_p2v1.png

                    After:
                    1_1538874838366_p2v2.png

                    It seems to be working correctly now, I can route as desired, but I am experiencing a couple of visual bugs in the UI of pfSense after doing so. I''ll make a new thread for that.

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      That looks correct. You can't route over policy based IPSec. But if you NAT the subnets you can make the traffic match an existing policy.

                      Steve

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