Hi,
after enabling VRRP (http://docs.frrouting.org/en/latest/vrrp.html) on our
OpenVPN servers I stepped into a strange problem regarding the UDP answer
packets from the Server.
If those packets (UDP 1194) originate on the VRRP-IP, which resides on a
macvtap interface, the server emits ARP requests with the remote
destination IP - as if the interface had a netmask /0. Of course nobody
answers this ARPs and the connection fails.
What I found here seems to describe the same problem:
https://forums.openvpn.net/viewtopic.php?t=7812
All other connections with that VRRP-IP work fine, even other UDP
connections (dns server). Only openvpn and only on this particular IPv4
(IPv6 works fine) is affected.
Maybe the way openvpn handles it's socket triggers a weird kernel
behaviour here, because the master interface (eth) and the enslaved
macvtap (vrrp) have different IPs on the same subnet and the interface
route on that macvtap device is active and inactive at the same time,
somehow?
If I trace with iptables I see the correct outgoing packet to the remote
IP. So somehow the kernel thinks it has to send ARP for it instead of
sending it to the default route nexthop.
Does this sound familiar to anyone? How to solve or workaround? Do I have
to write a fake arp responder which responds with the nexthop to all
strange arp requests?
Viele Grüße,
Frank
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
