22.05 - DCO and OpenVPN issue

stephenw10

That enabling DCO on the server end?

Clients still connect OK, just can't pass traffic?

Any errors logged?

swixo

@stephenw10
Just repeated it and looked at the OVPN logs. No errors that I can see with DCO on.
Clients connect OK - just no traffic.
Enabling DCO on server end yes.

stephenw10

Hmm, what clients are you using?

swixo

@stephenw10 Using the OpenVPN Client for IOS this AM. The Viscosity client on MacOS has the same issue.

stephenw10

Hmm, do you see:

[22.05-RC][admin@fw1.stevew.lan]/root: pkg info -s openvpn
openvpn-2.6.0_8                805KiB

Steve

swixo

@stephenw10

# pkg info -s openvpn
openvpn-2.6.0_8                836KiB

looks good. (Except file size)

Pippin

Filesize.....

maverick_slo

I have exact same filesize and version as @swixo
And if I turn ON DCO, traffic stops flowing on my android device.
Turn DCO OFF all is fine again...

swixo

@pippin Yep - I see that - disregarded initially.

swixo

@swixo Just reinstalled 22.01. Upgraded to 22.05RC.

pkg info -s openvpn
openvpn-2.6.0_8 836KiB

Client VPN behaved same - DCO=no data flow, no DCO, all ok.

stephenw10

Mmm, I was looking on a 3100 there though. On an amd64 machine it looks good:

[22.05-RC][admin@4100-2.stevew.lan]/root: pkg info -s openvpn
openvpn-2.6.0_8                836KiB

I assume the IOS client is still OpenVPN 2.5 based?

swixo

@stephenw10 Yeah - for me all iOS and MacOS have issue.
My platform for pf is all Netgate 1537 appliances.

jimp

I have seen an occasional glitch on OSX but I'm not sure if it's specific to OSX. The first start after a reboot sometimes it won't ping, but if I restart the server and reconnect the client it can. But since it's so intermittent and doesn't happen every time (and didn't log anything different that I recall), I hadn't been able to nail down anything solid enough to call a problem yet.

If you can reproduce it reliably, check the ifconfig output for the interface, the contents of the routing table, and the OpenVPN logs for when it doesn't work, then restart the server and see if you can reconnect the client and pass traffic. If you can, then compare the logs and other output and see if you notice any differences.

swixo

@jimp said in 22.05 - DCO and OpenVPN issue:

If you can reproduce it reliably, check the ifconfig output for the interface, the contents of the routing table, and the OpenVPN logs for when it doesn't work, then restart the server and see if you can reconnect the client and pass traffic. If you can, then compare the logs and other output and see if you notice any differences.

Ok! I tested and I was able to get traffic to flow ONCE after I closed the tunnel, restarted the server and restarted the tunnel. But subsequent initiations of the tunnel resulted in no data flow.

This is the ifconfig for the interface - and it was the same in the fail and non fail condition:

utun10: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
	inet 192.168.41.2 --> 192.168.41.2 netmask 0xffffff00

I didn't see anything error like in the logs. Just the usual stuff.

s

jimp

That looks like the client side, what about differences on the server side when it works vs when it doesn't?

swixo

@jimp I have not been able to 'jiggle' it into working by disconnecting/restarting and reconnecting again. It just fails:

This is ifconfig from Server side for each state

tunnel disconnected:

ovpns2: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet6 fe80::3eec:efff:fe79:f1f2%ovpns2 prefixlen 64 tentative scopeid 0x19
	inet 192.168.41.1 --> 192.168.41.2 netmask 0xffffff00
	groups: openvpn
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Connected/Failing (No data pass)

ovpns2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	inet6 fe80::3eec:efff:fe79:f1f2%ovpns2 prefixlen 64 scopeid 0x19
	inet 192.168.41.1 --> 192.168.41.2 netmask 0xffffff00
	groups: openvpn
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Hope this helps.

jimp

I think this is what I hit yesterday with multiple clients failing (only the first client, e.g. .2 worked). We got a fix in yesterday afternoon and made a new build. You should be able to update to that and try it.

swixo

This post is deleted!

swixo

@jimp I may have spoken too soon -- It worked once - but shortly after - same problem returned.

Did a server restart - and its blocking data again w/DCO. Sorry for any false start - just reporting what I'm seeing.

jimp

Odd. I can't reproduce any problem now, and I could before. I've restarted the server and clients multiple times. Not just reboots but daemon restarts.