[Openvpn-users] standby tunnel

[richard lucassen]

Hello list,

Is there an option to run a peer to peer tunnel which is up (tun
devices are there), but remains completely silent and only becomes
active when data is routed through the tunnel? So no keepalive, no
initializing.

IOW: a sort of encrypted version of an ipip tunnel. I think I can do
the trick using OpenSWAN (not sure), but I prefer OpenVPN.

R.

[Gert Doering]

Hi,

Post by richard lucassen
Is there an option to run a peer to peer tunnel which is up (tun
devices are there), but remains completely silent and only becomes
active when data is routed through the tunnel? So no keepalive, no
initializing.
IOW: a sort of encrypted version of an ipip tunnel. I think I can do
the trick using OpenSWAN (not sure), but I prefer OpenVPN.

If you do a peer-to-peer tunnel with static key, and no keepalive configured,
this is what it will do.

If you do TLS without keepalive, I think it will renegotiate ever so often
(like, every 12 hours) so you'll see marginal traffic even if there is
no activity - on the other side, the security level of TLS is much better,
so "static key" is not really recommended.

gert

[richard lucassen]

On Thu, 8 Jun 2017 10:36:13 +0200

Post by Gert Doering

Post by richard lucassen
Is there an option to run a peer to peer tunnel which is up (tun
devices are there), but remains completely silent and only becomes
active when data is routed through the tunnel? So no keepalive, no
initializing.
IOW: a sort of encrypted version of an ipip tunnel. I think I can do
the trick using OpenSWAN (not sure), but I prefer OpenVPN.

If you do a peer-to-peer tunnel with static key, and no keepalive
configured, this is what it will do.

I can set ping-restart to 0 to disable this function, but settin ping
to 0 just puts the ping back to the default of 10 sec. And the
keepalive option is AFAIUI just a wrapper for ping and ping-restart. I
cannot see how to disable the ping function.

Post by Gert Doering
If you do TLS without keepalive, I think it will renegotiate ever so
often (like, every 12 hours) so you'll see marginal traffic even if
there is no activity - on the other side, the security level of TLS
is much better, so "static key" is not really recommended.

Ok, but better than an ipip tunnel ;-) And there are firewall rules to
protect OpenVPN, it's just a real PtP VPN between two fixed ip's.

[Gert Doering]

Hi,

Post by richard lucassen
I can set ping-restart to 0 to disable this function, but settin ping
to 0 just puts the ping back to the default of 10 sec. And the
keepalive option is AFAIUI just a wrapper for ping and ping-restart. I
cannot see how to disable the ping function.

As long as you have *neither* keepalive nor ping in your config, it
should default to "0", not to "10s". Just checked the code.

gert

[richard lucassen]

On Thu, 8 Jun 2017 12:00:31 +0200

Post by Gert Doering

Post by richard lucassen
I can set ping-restart to 0 to disable this function, but settin
ping to 0 just puts the ping back to the default of 10 sec. And the
keepalive option is AFAIUI just a wrapper for ping and
ping-restart. I cannot see how to disable the ping function.

As long as you have *neither* keepalive nor ping in your config, it
should default to "0", not to "10s". Just checked the code.

Yep, you're right :)

But it still tries to initialize (which is quite obvious of course),
but is there a way to tell OpenVPN to only initialize the VPN as soon as
data enters the tunnel?

I know that I try to misuse OpenVPN ;-)

R.

[Gert Doering]

Hi,

Post by richard lucassen
On Thu, 8 Jun 2017 12:00:31 +0200

Post by Gert Doering

Post by richard lucassen
I can set ping-restart to 0 to disable this function, but settin
ping to 0 just puts the ping back to the default of 10 sec. And the
keepalive option is AFAIUI just a wrapper for ping and
ping-restart. I cannot see how to disable the ping function.

As long as you have *neither* keepalive nor ping in your config, it
should default to "0", not to "10s". Just checked the code.

Yep, you're right :)
But it still tries to initialize (which is quite obvious of course),
but is there a way to tell OpenVPN to only initialize the VPN as soon as
data enters the tunnel?

If you do static-key, there is nothing to initialize remotely - local
init, of course, as there is no tunnel interface otherwise.

With TLS, openvpn wants to set up the keying initally, and there is
no way today to delay that "until the first packet comes up" (at least
nothing I know of... there might be evil ways to do that with systemd
and socket-activation etc.)

gert

[richard lucassen]

On Thu, 8 Jun 2017 13:49:28 +0200

Post by Gert Doering

Post by richard lucassen
But it still tries to initialize (which is quite obvious of course),
but is there a way to tell OpenVPN to only initialize the VPN as
soon as data enters the tunnel?

If you do static-key, there is nothing to initialize remotely - local
init, of course, as there is no tunnel interface otherwise.

It's a simple static-key config:

dev tun0
local a.b.c.d
remote e.f.g.h
ifconfig 192.168.246.1 192.168.246.2
verb 5
secret /etc/openvpn/certs/secret.key
port 1198
proto udp
comp-lzo
user nobody
group nogroup

When starting it remains silent for 10 secs, but after these 10 secs it
starts to look for the other end:

# tcpdump -ni eth0 udp port 1198
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes
14:24:56.852049 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:06.830103 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:16.613951 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60

and so on.

R.

[Jan Just Keijser]

Hi,

Post by richard lucassen
On Thu, 8 Jun 2017 13:49:28 +0200

Post by Gert Doering

Post by richard lucassen
But it still tries to initialize (which is quite obvious of course),
but is there a way to tell OpenVPN to only initialize the VPN as
soon as data enters the tunnel?

If you do static-key, there is nothing to initialize remotely - local
init, of course, as there is no tunnel interface otherwise.

dev tun0
local a.b.c.d
remote e.f.g.h
ifconfig 192.168.246.1 192.168.246.2
verb 5
secret /etc/openvpn/certs/secret.key
port 1198
proto udp
comp-lzo
user nobody
group nogroup
When starting it remains silent for 10 secs, but after these 10 secs it
# tcpdump -ni eth0 udp port 1198
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes
14:24:56.852049 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:06.830103 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:16.613951 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60

just tested it over here:

when *starting* the tunnel, there is some initial traffic between client
and server, which is to be expected. After the PtP tunnel has been
established there is no traffic over UDP port 1198 , *until* traffic is
sent over the tunnel. The only thing I added to both client and server
configs was
keep-alive 0 0
which is the same as
ping 0
ping-restart 0

If you want *no traffic at all* until data is received on the tunnel
interface then you'll have to resort to ugly systemd-like tricks:
- use 'openvpn --mktun tun0' to create the tun device
- do something magic to launch openvpn when packets enteer tun0

but your initial packets will almost always time out - the initial
handshake in PtP mode is *at least* 10 seconds.

HTH,

JJK

[Gert Doering]

Hi,

Post by Jan Just Keijser
but your initial packets will almost always time out - the initial
handshake in PtP mode is *at least* 10 seconds.

There's a handshake in static-key mode? (Not talking about tls-client
to tls-server ptp mode)

gert

[Jan Just Keijser]

Hi,

Post by Gert Doering
Hi,

Post by Jan Just Keijser
but your initial packets will almost always time out - the initial
handshake in PtP mode is *at least* 10 seconds.

There's a handshake in static-key mode? (Not talking about tls-client
to tls-server ptp mode)

well, the static keys need to be checked, but what I've found is that both ends wait for 10 seconds before printing out
'Initialization complete" - I did not test whether you can send packets over the link sooner than that.

JJK

[richard lucassen]

On Thu, 8 Jun 2017 17:07:58 +0200

Post by Jan Just Keijser
well, the static keys need to be checked, but what I've found is that
both ends wait for 10 seconds before printing out 'Initialization
complete" - I did not test whether you can send packets over the link
sooner than that.

The initialization takes place immediately, as mentioned in another
post. AFAIUI there is no need for initialization of an udp static key
config.

R.

[Gert Doering]

Hi,

Post by Jan Just Keijser
well, the static keys need to be checked, but what I've found is that
both ends wait for 10 seconds before printing out 'Initialization complete"

As it turns out, this is actually OCC...

Post by Jan Just Keijser
- I did not test whether you can send packets over the link sooner than that.

You can :-) - I use that in one of my t_client setups. It will print
"Initialization complete!" the very moment the first packet comes *in*.

(Which actually broke t_client.sh in recent versions, as we now wait
for that line to show up before sending pings - so openvpn waits for a
packet, and packets are delayed waiting for openvpn... - fixed that with
an --up script which forks to the background and then sends 3 pings...)

gert

[richard lucassen]

On Thu, 08 Jun 2017 16:43:32 +0200

Post by Jan Just Keijser
keep-alive 0 0
which is the same as
ping 0
ping-restart 0

I tried that, but setting "ping 0" results in the default of 10 secs,
not disabling. The option "ping 0" is not mentioned in the manpage BTW.
setting ping-restart to 0 disables the option.

Removing the options disables the ping.

Post by Jan Just Keijser
If you want *no traffic at all* until data is received on the tunnel
- use 'openvpn --mktun tun0' to create the tun device
- do something magic to launch openvpn when packets enteer tun0

I have no systemd here...

Post by Jan Just Keijser
but your initial packets will almost always time out - the initial
handshake in PtP mode is *at least* 10 seconds.

[Gert Doering]

Hi,

Post by richard lucassen
# tcpdump -ni eth0 udp port 1198
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes
14:24:56.852049 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:06.830103 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60
14:25:16.613951 IP a.b.c.d.1198 > e.f.g.h.1198: UDP, length 60

Run
openvpn --verb <high>

(starting from 5, going up)

to see what it's doing...

gert

[richard lucassen]

On Thu, 8 Jun 2017 17:03:56 +0200

Post by Gert Doering
Run
openvpn --verb <high>
(starting from 5, going up)
to see what it's doing...

--verb 6

You can see the 10 secs wait:

Thu Jun 8 22:00:11 2017 us=709103 UDPv4 link remote:
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:21 2017 us=308356 Peer Connection Initiated with
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:22 2017 us=539641 Initialization Sequence Completed

And if the remote is down it will retry every 10 secs.

Another test:

I start local side. No udp packet in the first seconds. After 2 seconds
I start a ping from remote and immediately it initiates the tunnel:

Thu Jun 8 22:04:23 2017 us=902239 Peer Connection Initiated with
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:04:24 2017 us=905187 Initialization Sequence Completed

So why talk after 10 secs to the remote side while sending a ping will
do the job? There is no need for it using an udp static key config.

Anyway, I am trying this to achieve the following, maybe you guys have
an elegant idea to solve this problem:

I have two HA (High Availablity) active/passive clusters using virtual
ip (keepalived/conntrackd).

box1a--+ ip1a ip2a +-- box2a
| |
+ vip1 <-------> vip2 +
| |
box1b--+ ip1b ip2b +-- box2b

I have an unencrypted ipip tunnel between vip1 and vip2. Note: all 4
boxes have an ipip0 device that is up all the time. This works like a
charm because there is only 1 tunnel active between the two vip's. As
soon as one box becomes master, it will own the virtual ip and as the
ipip tunnel config contains the vip it will be the only one to be
capable of digging the tunnel. The passive one will not be able to dig a
tunnel because it does not own the virtual ip. Everything is handled by
the kernel. Ok, it has probably a high level of Q&D, but it works.

Ok, but now I want encryption. I was wondering if such a config would be
feasible using a peer to peer OpenVPN. Problem is that I cannot bind an
OpenVPN instance to the vip as this ip might disappear or simply not
be there when OpenVPN starts. Disadvantage of userspace daemons.

One of the options is to create a peer to peer OpenVPN tunnel over the
ipip connection. Both OpenVPN instances have the ipip tunnel ip's as
local and remote ip. For the slave the remote seems to be down.

I know I can tell keepalived to stop/start an OpenVPN instance and this
works fine of course, but I was just looking for an elegant option if
possible. Scripting is my "gateway of last resort".

R.

[Gert Doering]

Hi,

Post by richard lucassen
--verb 6
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:21 2017 us=308356 Peer Connection Initiated with
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:22 2017 us=539641 Initialization Sequence Completed
And if the remote is down it will retry every 10 secs.

Well, it's not showing any outgoing packets yet, so maybe it needs more
--verb.

In static key mode, there's no real "peer connection" to be "initiated",
as everything is static anyway. So it's not fully clear to me what it
is doing there.

(But I've never used static key mode in earnest, so I'll learn something
new here :) )

gert

[richard lucassen]

On Thu, 8 Jun 2017 22:47:35 +0200

Post by Gert Doering

Post by richard lucassen
--verb 6
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:21 2017 us=308356 Peer Connection Initiated with
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:22 2017 us=539641 Initialization Sequence Completed
And if the remote is down it will retry every 10 secs.

Well, it's not showing any outgoing packets yet, so maybe it needs more
--verb.

Setting verb to 8 makes a lot of noise :) That's why I just looked with
tcpdump.

Post by Gert Doering
In static key mode, there's no real "peer connection" to be
"initiated", as everything is static anyway. So it's not fully clear
to me what it is doing there.
(But I've never used static key mode in earnest, so I'll learn
something new here :) )

I think it's a glitch in the code which only pops up in this special
config. For normal use it should not be a problem.

R.

[Joe Patterson]

Just as a thought, have you tried running tcpdump on the tunnel interface
immediately after it comes up (before the 10 seconds), on the off chance
that this has nothing to do with openvpn, but instead something on the OS
side of things has decided that a new interface needs a packet or three
sent 10 seconds after it's created?

-Joe

Post by richard lucassen
On Thu, 8 Jun 2017 22:47:35 +0200

Post by Gert Doering

Post by richard lucassen
--verb 6
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:21 2017 us=308356 Peer Connection Initiated with
[AF_INET]e.f.g.h:1198
Thu Jun 8 22:00:22 2017 us=539641 Initialization Sequence Completed
And if the remote is down it will retry every 10 secs.

Well, it's not showing any outgoing packets yet, so maybe it needs more
--verb.

Setting verb to 8 makes a lot of noise :) That's why I just looked with
tcpdump.

Post by Gert Doering
In static key mode, there's no real "peer connection" to be
"initiated", as everything is static anyway. So it's not fully clear
to me what it is doing there.
(But I've never used static key mode in earnest, so I'll learn
something new here :) )

I think it's a glitch in the code which only pops up in this special
config. For normal use it should not be a problem.
R.
--
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
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Gert Doering]

Hi,

Post by Joe Patterson
Just as a thought, have you tried running tcpdump on the tunnel interface
immediately after it comes up (before the 10 seconds), on the off chance
that this has nothing to do with openvpn, but instead something on the OS
side of things has decided that a new interface needs a packet or three
sent 10 seconds after it's created?

That were my initial thoughts, but since these packets are just 60 bytes
in length (after encryption and openvpn overhead), it looks more like an
empty control packet (maybe it *is* a --ping packet after all).

gert

[Gert Doering]

Hi,

Post by richard lucassen

Post by Gert Doering
Well, it's not showing any outgoing packets yet, so maybe it needs more
--verb.

Setting verb to 8 makes a lot of noise :) That's why I just looked with
tcpdump.

tcpdump does not answer *why* it thinks it wants to send a packet.

gert

[richard lucassen]

On Fri, 9 Jun 2017 08:22:11 +0200

Post by Gert Doering

Post by richard lucassen
Setting verb to 8 makes a lot of noise :) That's why I just looked
with tcpdump.

tcpdump does not answer *why* it thinks it wants to send a packet.

No, that's true :) It just tries to establish the tunnel after 10
secs. Why it tries it after 10 seconds? Why not right at the start?:

This is a test setup:

Fri Jun 9 20:03:01 2017 us=154830 UDP link local (bound):
[AF_INET]192.168.247.1:1198

Fri Jun 9 20:03:01 2017 us=154847 UDP link remote:
[AF_INET]192.168.247.2:1198

Fri Jun 9 20:03:01 2017 us=154865 GID set to nogroup
Fri Jun 9 20:03:01 2017 us=154882 UID set to nobody

Fri Jun 9 20:03:11 2017 us=430648 Peer Connection Initiated with
[AF_INET]192.168.247.2:1198

Fri Jun 9 20:03:12 2017 us=648920
Initialization Sequence Completed

R.

[Gert Doering]

Hi,

Post by richard lucassen
On Fri, 9 Jun 2017 08:22:11 +0200

Post by Gert Doering

Post by richard lucassen
Setting verb to 8 makes a lot of noise :) That's why I just looked
with tcpdump.

tcpdump does not answer *why* it thinks it wants to send a packet.

No, that's true :) It just tries to establish the tunnel after 10

--verb 8 should tell - some event is going to fire, and I'm highly
curious what it is, given that there is nothing to negotiate in
static-key mode.

gert

[richard lucassen]

On Fri, 9 Jun 2017 20:29:29 +0200

Post by Gert Doering
--verb 8 should tell - some event is going to fire, and I'm highly
curious what it is, given that there is nothing to negotiate in
static-key mode.

When I sent the message I realized that --verb 8 made a lot of noise
yesterday, but now it looks like a --verb 4.

I'll try to find out what's going on. I'm quite busy experimenting all
sorts of configs.

BTW, is there a way to disable ipv6 in the tunnel? I can't find
anything about it in the manpage. There are ipv6 router sollicitations
flowing into the tunnel which is keeping the slave tunnel busy. Or do I
have to sysctl some /proc/sys/net/ipv6/tun0 entry?

[Gert Doering]

Hi,

Post by richard lucassen
BTW, is there a way to disable ipv6 in the tunnel? I can't find
anything about it in the manpage. There are ipv6 router sollicitations
flowing into the tunnel which is keeping the slave tunnel busy. Or do I
have to sysctl some /proc/sys/net/ipv6/tun0 entry?

Unless --ifconfig-ipv6 is set, we do not initialize anything IPv6-related
on the tun interface - so, this is your helpful OS (or network manager)
trying autoconfig to see if something happens.

so,

echo 0 >/proc/sys/net/ipv6/conf/tun0/router_solicitations

looks like it might do the job (could not find very clear answers online).

gert

[richard lucassen]

On Fri, 9 Jun 2017 23:04:40 +0200

Post by Gert Doering

Post by richard lucassen
BTW, is there a way to disable ipv6 in the tunnel? I can't find
anything about it in the manpage. There are ipv6 router
sollicitations flowing into the tunnel which is keeping the slave
tunnel busy. Or do I have to sysctl some /proc/sys/net/ipv6/tun0
entry?

Unless --ifconfig-ipv6 is set, we do not initialize anything
IPv6-related on the tun interface - so, this is your helpful OS (or
network manager) trying autoconfig to see if something happens.
so,
echo 0 >/proc/sys/net/ipv6/conf/tun0/router_solicitations

Yep, that did the trick. I added it to an "up" script

Post by Gert Doering
looks like it might do the job (could not find very clear answers online).

Here is a (temporary) upload of a --verb 9:

http://tmp.xaq.nl/ovpn.stdout

If an instance is not able to connect to the remote, it tries each 10
secs, than it gives up after 2 minutes or so. I cannot find any
parameters to reduce or to disable this. A --connect-retry-max 1 has no
influence (maybe it's tcp only?)

R.

R.

[Gert Doering]

Hi,

Post by richard lucassen

Post by Gert Doering
looks like it might do the job (could not find very clear answers online).

http://tmp.xaq.nl/ovpn.stdout

Thanks, that is actually quite enlightening :-)

At 12:38:19, things are set up properly (and it sends one packet, because
"read from tun/tap" returns one - that might be the OS doing IPv6 DAD,
hard to say).

At 12:38:29, you have:

Sat Jun 10 12:38:29 2017 us=760820 TIMER: coarse timer wakeup 1 seconds
Sat Jun 10 12:38:29 2017 us=760830 SENT OCC_REQUEST
...
Sat Jun 10 12:38:29 2017 us=761062 UDP WRITE [68] to [AF_INET]e.f.g.h:1198: DATA 3aa31726 fca6290a ad7ed8f6 54d9c125 1eb94c93 88c8383e a55bad67 59c8bfb[more...]

and then

Sat Jun 10 12:38:29 2017 us=767065 UDP read returned 228
Sat Jun 10 12:38:29 2017 us=767163 UDP READ [228] from [AF_INET]e.f.g.h:1198: DATA a637d087 d7b750e0 7985bd2e 0cc3e570 7087b20f 1521252c 0df6c8b4 bc89063[more...]
Sat Jun 10 12:38:29 2017 us=767392 Peer Connection Initiated with [AF_INET]e.f.g.h:1198
Sat Jun 10 12:38:29 2017 us=767405 RECEIVED OCC_REPLY


this is a bit misleading: in p2p mode, it will print "connection initiated"
the moment the first valid packet is received from the remote - so you
can have that after 1 second if you have a ping running on the other end...

10 seconds later, you pressed ctrl-c

Sat Jun 10 12:38:39 2017 us=383686 event_wait : Interrupted system call (code=4)
Sat Jun 10 12:38:39 2017 us=383699 I/O WAIT status=0x0010
Sat Jun 10 12:38:39 2017 us=383740 TCP/UDP: Closing socket
Sat Jun 10 12:38:39 2017 us=383782 Closing TUN/TAP interface

... so it's hard to say whether OpenVPN would have done anything else
in a 10-second-cycle afterwards.


Please try whether "--disable-occ" suppresses this. I think it might,
but it might only disable *checking* OCC, not *sending* - in which case
you need to recompile and remove the "#define ENABLE_OCC" line in
src/openvpn/syshead.h to really get rid of OCC. Worth a test.

gert

[richard lucassen]

On Sat, 10 Jun 2017 13:32:38 +0200

Post by Gert Doering

Post by richard lucassen
http://tmp.xaq.nl/ovpn.stdout

Thanks, that is actually quite enlightening :-)
At 12:38:19, things are set up properly (and it sends one packet,
because "read from tun/tap" returns one - that might be the OS doing
IPv6 DAD, hard to say).

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)

[..]

Post by Gert Doering
Please try whether "--disable-occ" suppresses this. I think it might,
but it might only disable *checking* OCC, not *sending* - in which
case you need to recompile and remove the "#define ENABLE_OCC" line
in src/openvpn/syshead.h to really get rid of OCC. Worth a test.

--disable-occ indeed makes the udp side silent, apart from the first
router sollicitations.

R.

[Gert Doering]

Hi,

Post by richard lucassen

Post by Gert Doering

Post by richard lucassen
http://tmp.xaq.nl/ovpn.stdout

Thanks, that is actually quite enlightening :-)
At 12:38:19, things are set up properly (and it sends one packet,
because "read from tun/tap" returns one - that might be the OS doing
IPv6 DAD, hard to say).

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.

Post by richard lucassen
[..]

Post by Gert Doering
Please try whether "--disable-occ" suppresses this. I think it might,
but it might only disable *checking* OCC, not *sending* - in which
case you need to recompile and remove the "#define ENABLE_OCC" line
in src/openvpn/syshead.h to really get rid of OCC. Worth a test.

--disable-occ indeed makes the udp side silent, apart from the first
router sollicitations.

Getting close :-)

gert

[richard lucassen]

On Sat, 10 Jun 2017 19:34:27 +0200

Post by Gert Doering

Post by richard lucassen
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

[Gert Doering]

Hi,

Post by richard lucassen

Post by Gert Doering

Post by richard lucassen
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.

"some bits of noise, but nothing bad"

So I take it's mostly working now?

[..]

Post by richard lucassen
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"'

Ugh. NAT involved. Any way to do this without (like, doing the tunnel
over IPv6)?

Post by richard lucassen
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.

That should be fine, then...

Post by richard lucassen
But maybe Gert or anyone else has a better OpenVPN-ish solution to
this :)

I'm afraid that *this* is outside OpenVPN's domain - you can play a bit
with --float, but that will break if port changes in a surprising way,
so both sides have the "wrong" remote port information all of a sudden.

gert

[richard lucassen]

On Mon, 12 Jun 2017 17:24:35 +0200

Post by Gert Doering

Post by richard lucassen
Well, in fact it does not matter very much. The slave is sending the
packet, but the response is sent back to the master.

"some bits of noise, but nothing bad"
So I take it's mostly working now?

Like a charm :)

Post by Gert Doering
Ugh. NAT involved. Any way to do this without (like, doing the
tunnel over IPv6)?

Nope. The problem is, whether it's ipv4 or ipv6, that the active tunnel
must bind to the virtual ip. And as only one OpenVPN server can have
the virtual ip, you will have to NAT. Using NAT I can bind both servers
to an internal 198.51.0.1. The daemon will then run on the master and
the slave without problems.

Outgoing packets: as the slave normally doesn't transmit and
receive data, I can SNAT the 198.51.0.1 to the virtual IP. On the
slave the udp packets are sent out anyway to the internet using the
source address of the virtual ip, although the slave does not own it.

Incoming packets: as soon as the slave becomes master, the udp packets
sent to the virtual ip wil be received and decrypted.

And as the routing tables on the slave and the master point to the tun
device itself, the routing table needs not to be changed during
master/slave switching.

This config doesn't need to switch on and off OpenVPN daemons and is
particularly interesting if you have two fail-over configs talking to
each other.

IMPORTANT NOTE: if only one of the sides has fail-over config, then a
simple --float on the server will do the job, even tcp can be used then.

Post by Gert Doering

Post by richard lucassen
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.

That should be fine, then...

Finally I think I'll go for the NOTRACK option. That's safe. No
bothering with connection track tables.

Post by Gert Doering

Post by richard lucassen
But maybe Gert or anyone else has a better OpenVPN-ish solution to
this :)

I'm afraid that *this* is outside OpenVPN's domain - you can play a
bit with --float, but that will break if port changes in a surprising
way, so both sides have the "wrong" remote port information all of a
sudden.

Well, that was exactly what I happened to discover. If the stack thinks
the src port is still in use, it will choose another src port. This
works of course using --float, but during master/slave switching the
conntrack tables are different which results in an interrupted VPN
connection.

Thnx for your support!

R.

[David Sommerseth]

Post by richard lucassen
On Fri, 9 Jun 2017 23:04:40 +0200

Post by Gert Doering

Post by richard lucassen
BTW, is there a way to disable ipv6 in the tunnel? I can't find
anything about it in the manpage. There are ipv6 router
sollicitations flowing into the tunnel which is keeping the slave
tunnel busy. Or do I have to sysctl some /proc/sys/net/ipv6/tun0
entry?

Unless --ifconfig-ipv6 is set, we do not initialize anything
IPv6-related on the tun interface - so, this is your helpful OS (or
network manager) trying autoconfig to see if something happens.
so,
echo 0 >/proc/sys/net/ipv6/conf/tun0/router_solicitations

Yep, that did the trick. I added it to an "up" script

The proper solution is actually to add this line in either
/etc/sysctl.conf or a file in /etc/sysctl.d. The line you would need
would then be:

net.ipv6.conf.tun0.router_solicitations = 0

This won't work too well if the tunnel isn't started before sysctl is
run during boot. But you can flip this around. On my systems, the
default value for IPv6 router_solicitations is 3. So if you know which
interfaces (being available at boot time) you want to have this enabled
on, you can do this:

net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.lo.router_solicitations = 3
net.ipv6.conf.enp0s25.router_solicitations = 3
net.ipv6.conf.wlp2s0.router_solicitations = 3


Or, you can use this in your 'up' script:

sysctl -p /etc/sysctl.d/tun-ipv6-tweak.conf

with /etc/sysctl.d/tun-ipv6-tweak.conf carrying the first example.

These approaches puts these configuration tweaks in your system which is
most commonly expected on Linux systems. And if others come and wants
to tweak it, they don't have to hunt down the 'up' script to figure out
what's going on.


--
kind regards,

David Sommerseth

[Gert Doering]

Hi,

Post by David Sommerseth
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.lo.router_solicitations = 3
net.ipv6.conf.enp0s25.router_solicitations = 3
net.ipv6.conf.wlp2s0.router_solicitations = 3

Indeed, good trick. Default to 0, re-enable everywhere else.

gert

[richard lucassen]

On Sat, 10 Jun 2017 21:03:01 +0200
David Sommerseth <***@sf.lists.topphemmelig.net> wrote:

[..]

Post by David Sommerseth
These approaches puts these configuration tweaks in your system which
is most commonly expected on Linux systems. And if others come and
wants to tweak it, they don't have to hunt down the 'up' script to
figure out what's going on.

I was already wondering what happens with sysctl settings to devices
that do not exist at the time of boot. I'll have a look at this matter
tommorow.

Thnx for your tips!

R.

[Antonio Quartulli]

Post by richard lucassen
On Sat, 10 Jun 2017 21:03:01 +0200
[..]

Post by David Sommerseth
These approaches puts these configuration tweaks in your system which
is most commonly expected on Linux systems. And if others come and
wants to tweak it, they don't have to hunt down the 'up' script to
figure out what's going on.

I was already wondering what happens with sysctl settings to devices
that do not exist at the time of boot. I'll have a look at this matter
tommorow.

without touching the defaults, one way could also be to disable RS *after* interface creation, but *before* bringing it up.
The RS packets are sent when the interface self configures itself after being brought up, so this should avoid sending such packets.

The only problem is that I believe you can’t tell OpenVPN to keep the interface down after initialisation.

Cheers,


--
Antonio Quartulli

[Gert Doering]

Hi,

The only problem is that I believe you can???t tell OpenVPN to keep the interface down after initialisation.

openvpn --mktun tun1
sysctl ...
openvpn --dev tun1 <normal options>

so easy... :)

gert

[Antonio Quartulli]

Post by Gert Doering
Hi,

The only problem is that I believe you can???t tell OpenVPN to keep the interface down after initialisation.

openvpn --mktun tun1
sysctl ...
openvpn --dev tun1 <normal options>
so easy... :)

oh great! I thought openvpn would complain about the interface name being already in use in this case. awesome :)

Cheers,


--
Antonio Quartulli

[Gert Doering]

Hi,

Post by Antonio Quartulli
oh great! I thought openvpn would complain about the interface name being already in use in this case. awesome :)

We have extra code to detect "oh, the interface existed beforehand,
so let's not destroy it on program end" :-)

gert

[David Sommerseth]

Post by Gert Doering
Hi,

Post by richard lucassen
On Thu, 8 Jun 2017 12:00:31 +0200

Post by Gert Doering

Post by richard lucassen
I can set ping-restart to 0 to disable this function, but settin
ping to 0 just puts the ping back to the default of 10 sec. And the
keepalive option is AFAIUI just a wrapper for ping and
ping-restart. I cannot see how to disable the ping function.

As long as you have *neither* keepalive nor ping in your config, it
should default to "0", not to "10s". Just checked the code.

Yep, you're right :)
But it still tries to initialize (which is quite obvious of course),
but is there a way to tell OpenVPN to only initialize the VPN as soon as
data enters the tunnel?

If you do static-key, there is nothing to initialize remotely - local
init, of course, as there is no tunnel interface otherwise.
With TLS, openvpn wants to set up the keying initally, and there is
no way today to delay that "until the first packet comes up" (at least
nothing I know of...

No, there is no such feature today. But I think this can make somewhat
sense though. It shouldn't be that hard to add a "wait for first
package on tun" on the client side, but that will not work from the
server side.

Since static key tunnels are bad by design (no PFS), it would be useful
to investigate how much efforts it would take to tweak a p2p tunnel
configuration with --tls-{client,server} to actually trigger the
connection on the first TUN/TAP packet. In these p2p tunnels the
routing on both sides are mostly predefined and don't depend on pushed
routes, so that could work.

Post by Gert Doering
there might be evil ways to do that with systemd
and socket-activation etc.)

Nope, can't even use systemd for that. Systemd can do some socket
activation based on the TCP/UDP port. In effect, this socket-activation
is basically a kind of xinetd feature with service management on top of
that.

I am not aware of any external tools which can observe what happens on a
pre-configured TUN/TAP device - including routing(!) - and can trigger
an action based on what kind of events happens.