Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    Pfsense dropping traffic from VPN

    Scheduled Pinned Locked Moved Firewalling
    4 Posts 3 Posters 2.3k 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.
    • I Offline
      inigoml
      last edited by

      Hi everybody.

      We have recently installed a new pfsense (vmware appliance) to replace an old IPTABLES-based firewall. Rules were ported without problem, but at the time of exchange both firewalls we have encountered a very strange behavior. I've never found something like this and we are thinking perhaps there is a hidden bug in rules generation that GUI don't show.

      Our pfsense has only two interfaces: LAN an WAN. WAN has three remote gateways:

      • gateway with traffic from and to internet.
      • gateway with internal traffic from a remote location VPLS based.
      • gateway with internal traffic from a remote location OpenVPN based.

      *** All traffic coming from VPN gateway is DROPPED without explanation. ***

      • Rules are the SAME from traffic that comes from VPLS based source and VPN based one. When I say SAME I want to say it's the same rule that include several sub-networks, five of them comming from VPN gateway and one of them comming from VPLS gateway.
      • We have added a rule from WAN in order to ALLOW EVERYTHING, but ONLY traffic coming from VPN does not enter.
      • When debugging via tcpdump, we have detected that packets PASS when coming from VPN gateway, reach our servers, and response is blocked by PFsense.
      • If we activate NAT in VPN gateway (and all traffic coming from VPN gateway appear to be originated from the proper gateway), everything works. Of course we loose source IP because it's replaced by VPN gateway.
      • Traffic originated in our LAN reachs remote subnetworks without any issue.
      • Routing is working and when we disable all firewalling in PFSENSE, traffic flow is normal and all packets coming from both VPN a VPLS gateways reach our internal network without problem.

      Any suggestion?????
      We don't know how to deal with these… I though I knew how to use a firewall but now I'm doubting.... :-)

      Thanks in advance!

      1 Reply Last reply Reply Quote 0
      • P Offline
        podilarius
        last edited by

        First, when you create a openVPN, you are going to see a new tab in your firewall rules table. This table is for firewalling the openvpn connection. By default, all ports are blocked. You will need to add a rule that will allow access across the VPN. That is of course assuming pfsense is the end point of the openvpn tunnel. If it is not, then you might just have a routing problem only.

        1 Reply Last reply Reply Quote 0
        • I Offline
          inigoml
          last edited by

          We are not using pfsense OpenVPN daemon. Our VPN gateway is outside pfsense.
          Sometimes we forget the benefits of rebooting a server… we rebooted pfsense and... voilá... problem solved!  ;) I we were windows users that would be our first option... but this is not windows world!

          1 Reply Last reply Reply Quote 0
          • J Offline
            jits
            last edited by

            Oh definitely…cycling the server is one of the first steps to do.

            Some years ago, we had a satellite uplink go down for no apparent reason and it was 12 hour conference calls, approaching 24 hours straight, until some old guy, almost choking on his umph cup of coffee, leaned over into his mic and said, "mmmm, coughcough* ...gentlemen, has anyone cycled the transceiver??"

            Trust me when I tell you, there was silence across the space in heavens for this one, until...a minute later, a small, still voice, almost a whisper said, "....the link is back up..."

            But who could blame the guy, when a week prior, someone tried to hack into the satellite, causing it's onboard defenses to fire the thrusters, moving the satellite either to the left or right of it's current position.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
            Privacy Policy · Cookie Policy