PFSENSE does not recognize the traffic for ipip tunnel
-
I have an ipip tunnel that establishes communication through two remote PFSense. This ipip tunnel is established from two PCs that are within the lan of each PFSense.
However, although it allows traffic, it does not show the traffic associated with this connection in the firewall log. (checking log packet in the associated rule).In addition, if any traffic on the PC that is performing the ipip tunnel is intentionally blocked, the tunnel is still in operation, that is, this traffic is not blocked for the IPIP tunnel connection. (there is no other additional rule)
result of packet capture
PFSENSE1 WAN: 192.168.1.20
PC1 LAN: 10.10.10.10PFSENSE2 WAN:192.168.2.20
PC2 LAN: 20.20.20.2019:35:06.349435 IP 192.168.1.20 > 192.168.2.20: IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x08000000,seq=0xee659), length 266 (ipip-proto-4)
19:35:12.784687 IP 192.168.1.20 > 192.168.2.20: IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x08000000,seq=0xee65a), length 778 (ipip-proto-4)
19:35:12.860748 IP 192.168.2.20 > 192.168.1.20: IP 20.20.20.20 > 10.10.10.10: ESP(spi=0x08000000,seq=0xcb44a0), length 778 (ipip-proto-4)
19:35:12.860799 IP 192.168.2.20 > 192.168.1.20: IP 20.20.20.20 > 10.10.10.10: ESP(spi=0x08000000,seq=0xcb44a1), length 778 (ipip-proto-4)
19:35:12.861005 IP 192.168.2.20 > 192.168.1.20: IP 20.20.20.20 > 10.10.10.10: ESP(spi=0x08000000,seq=0xcb44a2), length 778 (ipip-proto-4)
19:35:12.960406 IP 192.168.2.20 > 192.168.1.20: IP 20.20.20.20 > 10.10.10.10: ESP(spi=0x08000000,seq=0xcb44a3), length 778 (ipip-proto-4)
19:35:12.982344 IP 192.168.1.20 > 192.168.2.20: IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x08000000,seq=0xee65b), length 522 (ipip-proto-4)
19:35:13.106800 IP 192.168.1.20 > 192.168.2.20: IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x08000000,seq=0xee65c), length 522 (ipip-proto-4)
19:35:13.168119 IP 192.168.1.20 > 192.168.2.20: IP 10.10.10.10 > 20.20.20.20: ESP(spi=0x08000000,seq=0xee65d), length 522 (ipip-proto-4) -
Logging matching traffic would only ever log the first packet which created the state. Subsequent packets would not be logged. Additionally, since it's ESP, it's possible that the traffic is being passed by an automatic IPsec-related rule and not hitting your logging rule.
If there is an existing state for ESP from the source to the destination, then ESP traffic in either direction will be allowed, since it matches the state. Doesn't matter what the rules say unless the states expire or are killed after changing the rules.
