On 24.07.2017 18:15, Muenz, Michael wrote: > Here's one packet on enc0: > > > root@PB-FW1-FRA:~ # tcpdump -vni enc0 > tcpdump: listening on enc0, link-type ENC (OpenBSD encapsulated IP), > capture size 262144 bytes > 17:07:41.769313 (authentic,confidential): SPI 0x90b7ba72: IP (tos 0x0, > ttl 63, id 27752, offset 0, flags [none], proto ICMP (1), length 28, bad > cksum b72d (->b82d)!) > 10.26.1.1 > 10.24.66.25: ICMP echo request, id 41163, seq 28416, > length 8 > 17:07:41.777223 (authentic,confidential): SPI 0xcaae18f8: IP (tos 0x0, > ttl 58, id 44180, offset 0, flags [none], proto IPIP (4), length 48) > 81.24.74.3 > 213.244.192.191: IP (tos 0x0, ttl 63, id 46327, offset > 0, flags [none], proto ICMP (1), length 28) > 10.24.66.25 > 10.26.1.1: ICMP echo reply, id 41163, seq 28416, length 8 > 17:07:41.777240 (authentic,confidential): SPI 0xcaae18f8: IP (tos 0x0, > ttl 63, id 46327, offset 0, flags [none], proto ICMP (1), length 28) > 10.26.1.1 > 10.26.1.1: ICMP echo reply, id 33347, seq 28416, length 8
This does not match with what I expected to see. The reply here should be something like "10.24.66.25 > 10.26.2.N: ICMP echo reply". It seems the problem is with ipfw_nat, that for both directions thinks that packets are inbound and this leads to incorrect translation. Can you modify your IPsec security policies, so outgoing packets from 10.26.2.0/24 will go through the same tunnel? Then you need to modify nat rule: ipfw nat 1 config ip 10.26.1.1 ipfw add 179 nat 1 log ip from 10.26.2.0/24 to 10.24.66.0/24 out xmit enc0 ipfw add 179 nat 1 log ip from 10.24.66.0/24 to 10.26.1.1 in recv enc0 -- WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature