https://community.ipfire.org/t/core-update-167-ipsec-issue/7893/ I was able to reproduce this issue with an IPsec N2N connection between two IPFire machines running Core Update 167. Chain IPSECINPUT (1 references) pkts bytes target prot opt in out source destination 8 2300 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:500 17 5193 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 Chain IPSECOUTPUT (1 references) pkts bytes target prot opt in out source destination 15 3840 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:500 44 9068 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 While the IPsec tunnel is established properly, no traffic flows through it, and messages like these suggest we cannot scrap ESP from the firewall rules installed when a tunnel comes up. May 18 17:25:25 firewall kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=x DST=x LEN=140 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=ESP SPI=0xcb18bb02 MARK=0x8000cb00 May 18 17:25:26 firewall kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=x DST=x LEN=140 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=ESP SPI=0xcb18bb02 MARK=0x8000cb00 May 18 17:25:27 firewall kernel: DROP_INPUT IN=ppp0 OUT= MAC= SRC=x DST=x LEN=140 TOS=0x00 PREC=0x00 TTL=58 ID=0 DF PROTO=ESP SPI=0xcb18bb02 MARK=0x8000cb00 Root cause: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=28f659f75cfbbf21cd0fb8dd55b41af4203a0ecc
https://patchwork.ipfire.org/project/ipfire/patch/64c47b49-abd0-737b-5a93-6b621be190e2@ipfire.org/
(In reply to Peter Müller from comment #1) > https://patchwork.ipfire.org/project/ipfire/patch/64c47b49-abd0-737b-5a93- > 6b621be190e2@ipfire.org/ This is not the solution then. The original commit fixes a problem which is now back. If you want to keep the ESP/AH rules, they would have to be implemented on their own again.
https://patchwork.ipfire.org/project/ipfire/patch/822918e4-0bf4-a9b3-536c-f98e62468aca@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8077bacb826bb336d98d90c628ad8fece098dc16
https://blog.ipfire.org/post/ipfire-2-27-core-update-168-released