One way traffic over IPSec tunnel



  • Hi guys,

    I have this topo:

    Subnet 10.0.0.0/24-----Router1<---(static route)--->pfSense1<---IPSec--->pfSense2<-------->Router2-----subnet 10.1.1.0/24

    The IPSec tunnel between pfSense1 and pfSense2 was established successfully and all static routes were configured properly. Firewall rules on all interfaces were set to IPv4 any any for diagnostic purpose. Server 10.0.0.2 can ping server 10.1.1.2 but 10.1.1.2 can't ping 10.0.0.2.
    When I did trace route from 10.0.0.2 to 10.1.1.2: it went through expected path: Router 1, then pfSense 1, then pfSense 2 via IPSec tunnel, then Router 2 and server 10.1.1.2.
    But if did trace route from 10.1.1.2 to 10.0.0.2: ICMP packets were stopped at pfSense 2 as if pfSense2 didn't know route to 10.0.0.2.

    Version: pfSense1: 2.4.3; pfSense2: 2.4.3-p1

    Do you have any ideas to help me fix this issue? Thank you very much in advanced!

    Update Sep 12th 2018: problem solved!
    Reason: unintentionally NAT on Router 2 for outgoing traffic from 10.1.1.0/24 when traffic goes thro Router 2. I figured it out when I ping from 10.1.1.2 to 10.0.0.2 but the source IP address of this connection on Router 2 of this connection was the IP address of Router 2, not 10.1.1.2.

    Thank you very much for your discussion!



  • You don't need static route, when you make IPSEC connections - routes will be added automatically.



  • Thanks dave.opc. Static routing is used between Router 1 and pfSense 1 as well as between Router 2 and pfSense 2 for the two subnets 10.0.0.0/24 and 10.1.1.0/24 respectively. Between the two pfSense, I did not use static route because IPSec connection added the routes to 10.1.1.0/24 (for pfSense 1) and to 10.0.0.0/24 (for pfSense 2) respectively.


  • Netgate

    You need a phase 2 on the pfSense nodes for 10.0.0.0/24 <=> 10.1.1.0/24

    Everything on the pfSense 1 side needs to know to route traffic for 10.1.1.0/24 to pfSense 1.

    Everything on the pfSense 2 side needs to know to route traffic for 10.0.0.0/24 to pfSense 2.

    Anywhere that traffic enters a pfSense interface, the firewall rules there must pass it.



  • @Derelict I already configured IPSec Phase 2 on pfSense nodes for 10.0.0.0/24 <=> 10.1.1.0/24, that was why host 10.0.0.2 could ping 10.1.1.2. All firewall rules on all interface have been set to Any - Any.
    "Everything on the pfSense 2 side needs to know to route traffic for 10.0.0.0/24 to pfSense 2.": route to 10.0.0.0/24 on pfSense 2 should be installed via IPSec, shouldn't it? Here I don't think we need to configure static/dynamic routing on pfSense 2 to reach 10.0.0.0/24. Am I right?


  • Netgate

    If 10.0.0.2 can ping 10.1.1.2, then you obviously have good two way routing.

    If 10.1.1.2 cannot ping 10.0.0.2 then you have to look at the firewall rules where those connections enter firewall interfaces in that direction. INCLUDING the possibility that the firewall is on 10.0.0.2 itself.



  • @Derelict when I check log on router 2, the syslog said that packets from 10.1.1.2 going to 10.0.0.2 were forwarded correctly to pfSense 2.
    So the problem must be related to pfSense 2. I' working around on pfSense 2 to figure out the reason. It's quite strange because as I already mentioned: all firewall rules were set to Any Any on all interfaces: IPSec inf, the LAN interface on pfSense 2 connecting to Router 2.


  • Netgate

    What about a firewall on 10.0.0.2 itself? (Think Windows Firewall)



  • @Derelict I'm sure that it is configured properly. Packets from 10.1.1.2 stopped at pfSense 2, they even didn't reach pfSense 1 or Router 1 yet.


  • Netgate

    Then post all of the config screens from pfSense 2 I guess.



  • I'm am having the same issue. Traffic originating from location 1 flows to location 2 with no issues... but traffic originating from location 2 is stopped.. I have pfsense at location 1 and Sonicwall NSA at location 2. Hoping there are more answers forthcoming... my googlefoo finds that this issue happens frequently but nobody seems to have a good answer except 'it should create automatically', 'try manually creating rules', etc... the previous vpn between 2 sonicwalls worked fine.

    I've manually created rules with no change.


  • Netgate

    Like the other poster, going to need more information than "I created the rules."

    What rules? For what traffic? What is the IPsec configuration?

    You can pcap on the IPsec interface and initiate a connection from the other side. See if the traffic is even arriving. If not, it's on the other side or something is not cuorrect with the tunnel itself.



  • I have to assume the tunnel is setup properly since I can RDP thru it from location1 to location2 with no issues. However, I can 'initiate' any traffic from location2 to location1.

    Let's assume I created the tunnel and let the 'automatically' created traffic rules apply. Anything I need to do differently to get traffic to flow from location2 to location1 that I didn't need to do to allow traffic to flow from location1 to location2?


  • Netgate

    That could be firewall rules at the other side, or firewall rules on the IPsec tab.

    It could also be the local host refusing connections from the remote site based on its own firewall configuration.

    Like I said, a pcap will tell you more.


  • Netgate

    @showmemo said in One way traffic over IPSec tunnel:

    Let's assume I created the tunnel and let the 'automatically' created traffic rules apply.

    There are no automatically-created rules. You need to pass the traffic you wish to allow into the firewall from IPsec endpoints on the Firewall > Rules, IPsec tab.



  • @derelict I've created a 'Pass' any from any on the IPSEC tab, but it doesn't make any difference.

    I also have 2 other VPN's setup from other locations to location1 and they all have the same issue... location1 to any is fine, any to location1 (via vpn tunnel) fails.

    I can run a pcap, but everything points to the 1 issue - the pfsense firewall. The tunnels worked fine when I had a Sonicwall at location1, but once that was changed, and the tunnels re-established, the issue occurred.


  • Netgate

    Need more information to be able to have a chance at helping you.

    You can, of course, choose not to provide it and forgo any meaningful assistance.

    Either the other side is not sending the traffic to you or your firewall rules are incorrect.

    How about starting by posting the IPsec firewall rules and at least a Status > IPsec with the Phase 2 networks expanded and a detailed description of what traffic is not working (source address, dest address, dest port, etc).

    Packet capture on IPsec for the traffic and post that please.



  • interesting... I recreated the IPSEC rule for any to any, and it started working. I had done that and deleted it along with other rules.. maybe it was a timing thing.

    I've been setting up routers/vpn tunnels for a long while (think ISDN) and this seemed overly difficult and inconsistent for a basic VPN tunnel setup... just my 2c


  • Netgate

    Maybe you set protocol TCP on the rule or something.

    Impossible to say considering the lack of information provided.



  • @Derelict Here is the configuration on pfSense 2
    0_1536655450343_df519efa-fcf2-4e62-bf5b-b8a6eb0bb586-image.png

    And the route installed when IPSec tunnel established:
    0_1536655372719_dd01880e-a2c7-45fc-99ec-37120a8fc244-image.png

    0_1536655234803_e03a4e29-caf4-4b6a-a939-cd070be93969-image.png