All networks reachable over IPsec except one
-
Can you ping other CARP VIPs on the remote firewall?
-
-
Can you ping anything else in the 10.1.10.0/24 subnet?
Check the state table when pinging. Is it actually opening states correctly at the local end?
Ultimately run some pcaps to see where those pings are actually going.
-
@stephenw10
I cannot ping a host on that network - 10.1.10.59I have an extended ping going on. State is present
Traceroute dies on my firewall which i suspect is the problem (i dont see any logs on the remote side showing my ping attempts)
As i metioned, i do have static routes in place but i cant figure out why the firewall is not forwarding the traffic.
-
What interface(s) does it show that state on in the state table?
-
Thisis what i see in the state table. It is correct in that its coming in on the right interface.
There are no route conflicts
edit: Ok this is worrisome. I performed a pcap on the IPsec interface and nothing..
-
@stephenw10
Additoinal state information. I telnet to the CARP on port 443
But i see no state or anything in the firewall logs on the remote side.
So its for sure (i feel) failing on my firewall but i dont know why. -
Ok, so it comes in and never leaves.
That implies either there is no route for it or it's somehow blocked. Clearly there is a route.
Other things that might appear like that are:
Captive Portal running, though that would prevent the inbound state.
Blocked by Snort/Suricata.
Blocked by pfBlocker with logging disabled.
Conflicting policy based IPSec tunnel.
Policy routing on the rule via a gateway that is down perhaps?
-
From the cli of the firewall , pings work.
/root: ping 10.1.10.254 PING 10.1.10.254 (10.1.10.254): 56 data bytes 64 bytes from 10.1.10.254: icmp_seq=0 ttl=64 time=236.302 ms 64 bytes from 10.1.10.254: icmp_seq=1 ttl=64 time=236.178 ms 64 bytes from 10.1.10.254: icmp_seq=2 ttl=64 time=236.265 ms 64 bytes from 10.1.10.254: icmp_seq=3 ttl=64 time=236.193 msI agree there is something blocking
Captive Portal running, though that would prevent the inbound state.
- CP is not running on my system
Blocked by Snort/Suricata. - Neither of these packages are running
Blocked by pfBlocker with logging disabled. - I don't see it in my pfblocker Alerts/Unified tab but this is possible. I can try disabling although I read somewhere that pfBlocker makes a point to scrape through any list and remove RFC1918
Conflicting policy based IPSec tunnel.
- All my IPsec tunnels are Route Based not using Tunnel
Policy routing on the rule via a gateway that is down perhaps?
- Not utilizing PBR
- CP is not running on my system
-
I think...i might be on to something.
Status > IPsec > SPDs
Check out the 10.1.10.0/24 network. Why does that say Tunnel mode while the other s say VTI ?
This IPsec tunnel is VTI. Thats why other networks i can reach on this IPsec...Hmmmmm
-
Solved it!!
I restarted the IPsec dameon (via the GUI)
Cleared it uup right away as it probably had to rebuild the configuration on start up (is my guess)Super weird...Why was that the only network set up for Tunnel? Worse i had to restart the dameon.
-
Aha, nice!
Yup IPSec in policy mode can grab traffic and make it disappear like that.
