[strongSwan] broken arp support in Strongswan 5.7.2 ?

[Noel Kuntze]

Hello Harald,

That by itself is quite useless. Please provide the outputs of `ipsec statusall`
(or `swanctl -l`, depending on what frontend you're using), `ip route show table all`, `ip rule` and `ip address`.

Kind regards

Noel

Am 26.08.19 um 14:48 schrieb Harald Dunkel:
> Hi folks,
>
> road warrior setup:
>
> If I disconnect the cable, wait for Network Manager to
> recognize, and enable IPsec over WLAN to connect to the
> same network, then some hosts become inaccessible.
>
> tcpdump on such an inaccessible host (CentOS 7.4) shows:
>
> # tcpdump -envi eno1 icmp
> tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
> 13:25:00.000842 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51353, offset 0, flags [DF], proto ICMP (1), length 84)
>     10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 1, length 64
> 13:25:00.000874 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 47437, offset 0, flags [none], proto ICMP (1), length 84)
>     10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 1, length 64
> 13:25:01.021662 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51561, offset 0, flags [DF], proto ICMP (1), length 84)
>     10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 2, length 64
> 13:25:01.021686 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 48192, offset 0, flags [none], proto ICMP (1), length 84)
>     10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 2, length 64
> 13:25:02.045154 80:ee:73:a2:e6:16 > a4:bf:01:37:0b:26, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51567, offset 0, flags [DF], proto ICMP (1), length 84)
>     10.19.97.9 > 10.19.96.156: ICMP echo request, id 13502, seq 3, length 64
> 13:25:02.045187 a4:bf:01:37:0b:26 > 28:d2:44:3d:86:74, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 48515, offset 0, flags [none], proto ICMP (1), length 84)
>     10.19.96.156 > 10.19.97.9: ICMP echo reply, id 13502, seq 3, length 64
>
> Please note the bad destination mac used for the echo reply.
> It is still the mac for the cable connection. How comes? Ain't
> the arp table entries supposed to be overwritten on the first
> incoming package using the new mac address?
>
> All IPsec peers run Debian 9.9 and Strongswan 5.7.2. The IPsec
> gateway uses the dhcp and farp plugins to obtain the same IP
> address as for the cable connection.
>
> The dhcp server runs Debian 9.9 and isc-dhcp-server 4.3.5-3+deb9u1.
>
>
> Every insightful comment is highly appreciated.
>
> Harri

-- 
Noel Kuntze
IT security consultant

GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190826/67ebc4dc/attachment.sig>