[SOLVED] Error with address length ?

Arooo

Hello all,

Yes, first post 🙂 Perhaps because I'm not used to have problems.

... I'm an old user of OpenVPN, and never had any problem with it, since today, all went smoothly ... today I'm changing my gateway, wich hosts multiple instances of openvpn with a local PKI, each connection beeing launched through xinetd. The gateway runs Centos 6.0 on a (quite old) Dell PE SC1425 and (official provided package) OpenVPN 2.2.0-3, with all dependences solved by the distrib, no "special tunning" except a strong netfilter set which has proved to be fully fonctionnal on three other gateways.

... What else ? ... hum ... my previous OpenVPN was running Mandriva 2009.0, worked smoothly ... I use dedicated UDP ports for each user (5001 -> 5020) ...

Now my problem :

[color=#0000FF]
Dec 20 10:53:52 cerbere openvpn[26247]: OpenVPN 2.2.0 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] built on Jun  5 2011
Dec 20 10:53:52 cerbere openvpn[26247]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 20 10:53:52 cerbere openvpn[26247]: Diffie-Hellman initialized with 1024 bit key
Dec 20 10:53:52 cerbere openvpn[26247]: Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
Dec 20 10:53:52 cerbere kernel: tun0: Disabled Privacy Extensions
Dec 20 10:53:52 cerbere openvpn[26247]: TUN/TAP device tun0 opened
Dec 20 10:53:52 cerbere openvpn[26247]: TUN/TAP TX queue length set to 100
Dec 20 10:53:52 cerbere openvpn[26247]: /sbin/ip link set dev tun0 up mtu 1500
Dec 20 10:53:52 cerbere openvpn[26247]: /sbin/ip addr add dev tun0 local 10.67.80.1 peer 10.67.80.2
Dec 20 10:53:52 cerbere openvpn[26247]: Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec 20 10:53:52 cerbere openvpn[26247]: Local Options hash (VER=V4): 'xxxxxxxxxxxxxx'
Dec 20 10:53:52 cerbere openvpn[26247]: Expected Remote Options hash (VER=V4): 'yyyyyyyyyy'
Dec 20 10:53:52 cerbere openvpn[26247]: UID set to nobody
Dec 20 10:53:52 cerbere openvpn[26247]: UDPv4 link local: [inetd]
Dec 20 10:53:52 cerbere openvpn[26247]: UDPv4 link remote: [undef]
Dec 20 10:53:52 cerbere openvpn[26247]: ERROR: received strange incoming packet with an address length of 28 -- we only accept address lengths of 16.
Dec 20 10:53:52 cerbere openvpn[26247]: Exiting
Dec 20 10:53:52 cerbere openvpn[26247]: Closing TUN/TAP interface
Dec 20 10:53:52 cerbere openvpn[26247]: /sbin/ip addr del dev tun0 local 10.67.80.1 peer 10.67.80.2
Dec 20 10:53:52 cerbere openvpn[26247]: Linux ip addr del failed: external program exited with error status: 2
Dec 20 10:53:52 cerbere xinetd[26122]: EXIT: openvpn_FS status=1 pid=26247 duration=0(sec)
[/color]

I googled a lot arround this string, and could not find any references to a similar problem, the only close matches only driving me to the source of socket.c ... wich I'm not sure to be able to analyse :/

Has anyone faced (and solved) such a problem ?

cheers - OG

Arooo

Erratum : The package is not native, but comes from RPMForge, and is rhel6 related ... just tried V 2.1.4 from same source : same result.

Cheers - OG

janjust

seems like the server is returning IPv6 packets, either outside or inside of the tunnel; try disabling IPv6 on both ends to see if it makes a difference.

Arooo

Hi, & thx for your fast answer.

Well, you're probably right, at least for client side, as I noticed some logs for xinetd saying :

Dec 20 14:01:51 cerbere xinetd[27141]: START: openvpn_FS pid=29161 from=::ffff:88.191.40.199

But this still occures with ipv6 module blacklisted on both sides ... I'm stuck at this state, still searching :/

janjust

there's something odd with your routing if you're receiving IPv6 packets - OpenVPN normally does not process IPv6 traffic at all. Can you check the output of 'ifconfig -a' to make sure that IPv6 is now indeed gone?

Arooo

Hi Janjust,

Yes, IPV6 is indeed gone, but I wonder how far the public interface of the server could be the cause : it is a bridge merging two physical IFs each connected to an active/passive set of two routers (the main SDSL one and the backup ADSL one, provided as-is by my ISP), could this bridge cause any problem to OpenVPN ?

Thx - O.G.

Arooo

Hum ... no ... tried on an other public address on a physical IF ... Same pb :/

janjust

I'm starting to suspect that this is not an IPv6 address but simply a garbled packet; run a packet sniffer like tcpdump or wireshark and watch out for the offending packet - what does wireshark report about it?

Arooo

Well ... I run several other gateways using OpenVPN without any problem and almost each addressed both in IPV4 and IPV6, this only one is suing me, and it has IPV6 off, just like it's (unique) client ... when reading the logs, I do agree in saying it *looks* like an IPV6 related problem ... but the fact is that IPV6 is not on the path so ...

I captured a few packets on the server and posted them here : http://pastebin.com/BTCvDC9v , but I'm affraid I'm not so sharp that I can analyse them properly, would you mind to have a look ?

Thx a lot - O.G.

janjust

the packet capture shows IPv4 traffic only and it only shows traffic outside of the tunnel; can you rerun and now listen on the tunnel adapter itself ?

this is a long shot, but can you also add

multihome

to the server config file and try again - it slightly affects how the error message you're seeing is generated.

Arooo

Hi JanJust, and once again, thx for your help 😉

I tried to add th "multihome" parameter, and "nobind" on the client side, but this changes nothing, I'm still stuck on the same error. I wish I could listen on the tunnel adapter, but as you can see in the previous logs, it doesn't stay up even a single second :

Dec 22 10:22:27 cerbere openvpn[11161]: TUN/TAP device tun0 opened
Dec 22 10:22:27 cerbere openvpn[11161]: TUN/TAP TX queue length set to 100
Dec 22 10:22:27 cerbere openvpn[11161]: /sbin/ip link set dev tun0 up mtu 1500
Dec 22 10:22:27 cerbere openvpn[11161]: /sbin/ip addr add dev tun0 local 10.67.80.1 peer 10.67.80.2
Dec 22 10:22:27 cerbere openvpn[11161]: Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec 22 10:22:27 cerbere openvpn[11161]: Local Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,ifconfig 10.67.80.2 10.67.80.1,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Dec 22 10:22:27 cerbere openvpn[11161]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,ifconfig 10.67.80.1 10.67.80.2,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Dec 22 10:22:27 cerbere openvpn[11161]: Local Options hash (VER=V4): 'ed992b1c'
Dec 22 10:22:27 cerbere openvpn[11161]: Expected Remote Options hash (VER=V4): '57c65ac4'
Dec 22 10:22:27 cerbere openvpn[11161]: UID set to nobody
Dec 22 10:22:27 cerbere openvpn[11161]: UDPv4 link local: [inetd]
Dec 22 10:22:27 cerbere openvpn[11161]: UDPv4 link remote: [undef]
Dec 22 10:22:27 cerbere openvpn[11161]: ERROR: received strange incoming packet with an address length of 28 -- we only accept address lengths of 16.
Dec 22 10:22:27 cerbere openvpn[11161]: Exiting
Dec 22 10:22:27 cerbere openvpn[11161]: Closing TUN/TAP interface

... Anyway, the "strange incoming packet" could indeed cross the tunnel, since the error occures while tun0 is up ... I' looking for an option on the scanners I know, that could wait for an IF to be up before begining the capture ... stay tuned 😉

Thx - O.G.

Arooo

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

janjust

doh - I just now realized that you're starting OpenVPN from xinetd ; can you add a flag

flags           = IPv4

to the xinetd.conf file?

Arooo

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

Arooo

Hi again 🙂

That's it (yes, I managed to test today finaly ...) the [flags = IPV4] solved the problem.

Janjust, if one day you're on by Paris, please let me know it 😉 I ow u a beer (at least).

Thx a lot again.

O.G.