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

    Packets to remote subnet not going through IPsec

    IPsec
    2
    7
    2.4k
    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.
    • T
      terranean
      last edited by

      Hi everyone,

      no sure if this topic belongs here or in the routing section, I'll just start here.

      We have a problem with the network setup described in the attached network plan. The Firewalls in the picture are pfSense 1.2.3.

      We would like to make HTTP accesses to the VOIP phones in the VOIP subnet (192.168.105.0/24) behind the left firewall from the LAN (192.168.120.0/24) behind the right firewall.
      There's an IPsec connection between the two firewalls, tunneling 192.168.100.0/21 and 192.168.120.0/21.

      The problem is that connections to a 192.168.105.x IP go out through the default route instead of going through the IPsec tunnel. Packets to the remote LAN (192.168.100.0/24) and the remote DMZ (not shown in the pic, 192.168.101.0/24) on the other hand happily travel through the tunnel.

      I'd be grateful if someone here could enlighten me about the reason for this.

      Cheers,

      Chris
      voip-problem.png
      voip-problem.png_thumb

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        Do you have multi-WAN or a gateway set on the rule for the VOIP phones on the LAN side of that firewall?

        A gateway in a pf rule can make traffic bypass the usual ways that traffic should pass, though I don't recall if that applies to IPsec offhand. IPsec usually grabs what it wants as long as the subnet matches.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • T
          terranean
          last edited by

          No multi-WAN and no gateway in any pf rule.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            You'll probably need a second IPsec tunnel then that will match the VOIP subnet on the left side.

            In 2.0 you can have multiple subnets for each tunnel; In 1.2.3 you need two separate tunnels.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • T
              terranean
              last edited by

              That's a good idea, I'll definately try that. However, since the subnet masks for the tunnel match all involved subnets this shouldn't be necessary, right?

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                But it doesn't. :-)

                192.168.100.0/21 really is 192.168.96.0 - 192.168.103.255.

                Run it through a subnet calculator and you'll see, it doesn't add up the way you think it does.

                Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • T
                  terranean
                  last edited by

                  Gah, thanks for the clue-bat!

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