On Sat, 10 Jun 2017 19:34:27 +0200
Gert Doering <g...@greenie.muc.de> wrote:
> > It's a router sollicitation, it pops up in the remote tun device.
> > The tun device comes up and the up script for disabling router
> > sollicitations is invoked afterwards (which is obvious because
> > disabling router sollicitations is impossible when the device is
> > not there yet)
>
> Slightly annoying. This particular one might be avoided, though, by
> creating the tunnel beforehand ("openvpn --mktun tun0"), then
> disabling RS on it, and *then* running "openvpn --dev tun0 ..." on
> the pre-existing tunel device.
Well, in fact it does not matter very much. The slave is sending the
packet, but the response is sent back to the master. That's BTW exactly
what I had in mind (I wanted to create an encrypted tunnel similar to
an ipip tunnel between two VRRP clusters)
Note: the tunnel is active between the two masters because they own the
VIP and I force a ping from one of the *inactive* slaves:
on local slave:
$ ping -I 10.121.0.2 10.122.4.1
local slave (only the request is sent):
# tcpdump -ni tun0
22:28:57.719326 IP 10.121.0.2 > 10.122.4.1: ICMP echo request, id
26105, seq 37, length 64
remote master (receives request AND replies to the request):
# tcpdump -ni tun0
22:28:58.019811 IP 10.121.0.2 > 10.122.4.1: ICMP echo request, id
26105, seq 37, length 64
22:28:58.020238 IP 10.122.4.1 > 10.121.0.2: ICMP echo reply, id 26105,
seq 37, length 64
local master (sees a reply to a request that has never been sent):
# tcpdump -ni tun0
22:28:58.020980 IP 10.122.4.1 > 10.121.0.2: ICMP echo reply, id 26105,
seq 37, length 64
But there is still one tricky problem: the incoming NAT may change the
src port of the stream. That is why OpenVPN sometimes logs something
like 'src port (1024) unexpected instead of 1198, please remove
"remote" or use "float"'
That's quite nasty. The master and slave conntrack database must remain
the same for a smooth failover. So I needed to add an extra SNAT in the
INPUT chain to sport 1198. This way I will force the source port ever
to be 1198 (I hope)
I can also go for a NOTRACK target and put a rule above the ESTABLISHED
rule. But I think I'll go for an extra SNAT rule. Once the connection is
established, it won't be hit again.
But maybe Gert or anyone else has a better OpenVPN-ish solution to
this :)
R.
config on both sides (with some slight differences of course) The ip
198.51.0.1 is an internet non-routable IETF TEST-NET2 network that runs
on a dummy device. I have to use NAT to avoid that OpenVPN does not
start due to an absence of the (virtual) ip it is bound to. The NATted
ip is always there.
-t nat -A INPUT -s e.f.g.h -p udp --dport 1198 \
-j SNAT --to-source :1198
-t nat -A PREROUTING -d e.f.g.h -p udp --dport 1198
-j DNAT --to 198.51.0.1:1198
-t nat -A POSTROUTING -o eth0 -s 198.51.0.1 -p udp --sport 1198 \
-j SNAT --to-source e.f.g.h:1198
OpenVPN:
dev tun0
disable-occ
local 198.51.0.1
remote e.f.g.h
ifconfig 192.168.247.1 192.168.247.2
verb 4
secret /etc/openvpn/certs/secret.key
lport 1198
rport 1198
proto udp
comp-lzo
persist-tun
persist-key
user nobody
group nogroup
cipher AES-256-CBC
no-replay
script-security 2
up /etc/openvpn/up/up-tun0.sh
--
richard lucassen
http://contact.xaq.nl/
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
