Odd One way IPSec Communication issue
-
Re: IPSec One Way Communication… Sorta
Hello,
I am having the exact same symptoms as described by borsaid in the referenced topic. I, however, do not have any manual block ANY ANY rules that turned out to be the cause in borsaid's case. this is pretty much a default install and i only set up the VPN.
I am running 2.4.4_3 the other end of the VPN is a Fortinet Fortigate. I looked over it with Fortinet support and we don't see any VPN or routing issues. we just send out requests and never get replies, until the something on the pFsense side pings the FortiGate side.
Thanks to anyone who can provide some insight.
-
What rules do you have on your IPsec tab?
-
The ipsec tab has one rule. it is allow, source is the remote subnet, any protocol, destination local subnet.
When I do a trace when the ping doesn't work I see the pings come in from the IP of the remote subnet, but no reply from the ips in the local subnet.
Do I need a rule for the opposite direction as well? If that is the case, why would pings initiating from the local subnet to the remote subnet work without issue?
Thanks.
-
Show a screenshot of the rule.
You should only need a rule on the IPsec tab, but you need to check every leg of the connection. Run a packet capture on IPsec. If it arrives there, run a packet capture on the LAN for example. If it leaves the LAN and doesn't come back -- then it's being blocked locally on the LAN device, not pfSense. That or maybe the LAN device isn't using pfSense as its gateway.
You have to step through and consider what is happening at every point, and find out exactly where the traffic is stopping. Check the state table and see what it shows for traffic to/from the remote address.
There is a whole list of general connectivity items to check here: https://docs.netgate.com/pfsense/en/latest/routing/connectivity-troubleshooting.html
-
I have done that. Firewall on the lan device is off. pfSense can ping the lan device and lan device can ping pfSense. Again, from the pfSense site everything can communicate out just fine. a packet trace from the fortigate on the remote site shows the packet leaving. the trace on the pfsense at the same time shows the "Echo (ping) request" coming from the remote lan device" but no response. running wireshark on the local lan device shows nothing coming in. then I ping the remote lan device from the local lan device and the replies for the ping from the other direction start.
It seems like pfSense doesn't know what to do with incoming packets from the VPN, unless something is initiated from inside.
is this an issue with Phase 2 of IPSEC? or is an Auto pfSense Firewall rule blocking something it shouldn't?
-
Here are some IPSec logs that seem to just repeat:
Feb 13 08:03:43 charon 12[NET] <con1000|7> received packet: from a.a.a.a[4500] to b.b.b.b[4500] (108 bytes)
Feb 13 08:03:43 charon 12[ENC] <con1000|7> parsed INFORMATIONAL_V1 request 2100733347 [ HASH N(DPD_ACK) ]
Feb 13 08:03:43 charon 12[IKE] <con1000|7> activating new tasks
Feb 13 08:03:43 charon 12[IKE] <con1000|7> nothing to initiate
Feb 13 08:04:03 charon 10[IKE] <con1000|7> sending DPD request
Feb 13 08:04:03 charon 10[IKE] <con1000|7> queueing ISAKMP_DPD task
Feb 13 08:04:03 charon 10[IKE] <con1000|7> activating new tasks
Feb 13 08:04:03 charon 10[IKE] <con1000|7> activating ISAKMP_DPD task
Feb 13 08:04:03 charon 10[ENC] <con1000|7> generating INFORMATIONAL_V1 request 2734378732 [ HASH N(DPD) ]
Feb 13 08:04:03 charon 10[NET] <con1000|7> sending packet: from a.a.a.a[4500] to b.b.b.b[4500] (108 bytes)
Feb 13 08:04:03 charon 10[IKE] <con1000|7> activating new tasks
Feb 13 08:04:03 charon 10[IKE] <con1000|7> nothing to initiate
Feb 13 08:04:03 charon 10[NET] <con1000|7> received packet: from a.a.a.a[4500] to b.b.b.b[4500] (108 bytes)
Feb 13 08:04:03 charon 10[ENC] <con1000|7> parsed INFORMATIONAL_V1 request 2029219918 [ HASH N(DPD_ACK) ]
Feb 13 08:04:03 charon 10[IKE] <con1000|7> activating new tasks
Feb 13 08:04:03 charon 10[IKE] <con1000|7> nothing to initiatedoes that seem normal? it seems to be the same whether the pings are running or not, and my tunnel always stays up.
-
You say "I have done that" but you left out a lot of information I asked for, and a lot of tests from the page I linked.
If Status > IPsec looks the same (Tunnel + Child SA up) at point times then it almost certainly is not something in IPsec.
When you run the capture on pfSense, do you see it leave the LAN?
What does the state table look like when searching for the remote address when trying to initiate traffic remotely?
Show a screenshot of your IPsec tab rules
-
@jimp
When you say LAN do you mean the LAN on pfSense side? or LAN on Fortigate side?Scenario 1 - Pinging for LAN device on Fortigate site to LAN device on pfSense site.
pfSense capture shows incoming echo requests from Fortigate LAN device, but no return traffic
Fortigate Capture shows outgoing echo replies from Fortigate LAN device and not incoming traffic
pfSense LAN device shows no traffic from Fortigate LAN DeviceScenario 2 - Pinging from pfSense LAN device to Fortigate LAN Device.
It Works! all captures show expected results: echo requests and replies.
Scenario 3 - running a continuous ping from pfSense LAN device to Fortigate LAN device, then Pinging from Fortigate LAN device to pfSense LAN device.
again everything works. I see echo requests from both sources and echo replies from both destinations.
I attached a screenshot of my ipsec tab rules. 10.99.1.0/24 is the LAN network on the Fortigate side
and states while an unsuccessful ping:
I looked at the firewall logs and figured out how to use the filter! the ping is getting blocked by the default deny rule IPv4:
did I do something wrong on my IPsec rule shown above?
I do appreciate your assistance.
-
Your IPsec tab rule has the protocol set to TCP. It should be Any.
-
@jimp
Yup, i was just typing up a response saying I found that while reviewing my post. It's always the little things. thanks for guiding me through the troubleshooting steps!edit: It also was set to "LAN Address" instead of "LAN Net"
