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

    Traffic Isnt Jumping on Tunnel

    OpenVPN
    2
    6
    1.0k
    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.
    • J
      jacraine
      last edited by

      I recently set up a Site to Site OpenVPN connection between our main pfSense Firewall and an off-site location (see below).

      Site A 10.X.X.X <->pfsense1 LAN (10.X.X.X)<->pfsense1 (VPN: 10.100.124.1-server)<->INTERNET<->pfsense2(VPN:10.100.124.2-client)<->pfsense2 LAN (192.168.X.X)<->Site B 192.168.X.X

      Currently Site A can route and access anything on Site B (ping / network resouces / etc) but Site B cannot ping pass the pfsense2 box. The routing tables on both pfsense machines look perfect and the remote networks seem to be set up fine on both as well. Site B's clients have a route saying to go to pfsense2's LAN IP to access the 10.X.X.X network but the traffic stops dead there.

      Both pfsense's have any/any rules in the firewall for both normal and OpenVPN firewalls, in fact, NAT'ing and Firewall are completely disabled for pfsense2 (its between another firewall anyways).

      Any suggestions? Beat my head against the wall for two days so far on this with no luck.

      Thanks!

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        Because you can access B from A, that means that B devices do have effective routes back to A. So the routing should also be OK for states that originate from B going to A.
        Sounds like some firewall issue on pfSense1 on the incoming OpenVPN interface is not allowing traffic from Site LAN IPs to SiteA LAN IPs.
        And I assume that 10.x.x.x is not 10.0.0.0/8 - otherwise it overlaps the VPN tunnel. Those are all private addresses, so you can put the real numbers you are using - none of us can DOS you at private IPs:)
        If it is all as you describe then it should work. There will be some little setting/rule in error/overlooked. For us to help you spot that, you really need to post actual screen shots.

        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
        • J
          jacraine
          last edited by

          Thanks for taking the time to respond!

          Below are the rules for this VPN Subnet on pfsense1:

          Server Config:

          Client Config:

          The 10.2.X.X/16 subnet could be a bit overlapping with the 10.100.124.0/24 subnet, but this is the only instance (6 other OpenVPN [non-site to site]) that is having issues.

          Thanks again!

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            No overlap there - 10.2.0.0/16 is only all addresses starting with "10.2".
            The rules for the VPN subnet on pfSense1 are not showing enough of the page - allowing traffic from just 10.100.124.0/24 will not be enough. You need to allow traffic from those 192.168 subnets. But I can see that there is another pass rule coming further down - can't quite read it!
            For testing, and since this is all internal traffic anyway, I would be putting a pass all rule at the top of the OpenVPN tab. Then see if connectivity works. After that you can put more restrictive rules and then you know when it breaks that it is the rule-set you just applied.

            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
            • J
              jacraine
              last edited by

              Phil, you are my hero!

              That was it, I didn't think a rule to allow the 192.168 subnet would be necessary. That did it though! Now I'll have to clean up the rules but we have full connectivity now. I appreciate your help!

              Thank you so much sir!

              1 Reply Last reply Reply Quote 0
              • P
                phil.davis
                last edited by

                Happy to help.
                The addresses checked in rules are the real source and destination addresses of the packets arriving on the interface, which often (usually) are not in the interface subnet itself.

                This only gets "messed up" when there is NAT happening somewhere - if you are receiving packets that have been NATed somewhere by the sender then the source IP (destination when heading back to the NAT) will be whatever the NAT rewrote it to.

                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
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.