Mailing List Archive

changes to VPN profile, result: no IP traffic after VPN comes up
Hello,

Caused by a dead Cisco 3000 concentrator we got new VPN profiles xxx.pcf
to connect to another concentrator with some other IP and credentials.
Based on the PCF file I created the new vpnc.conf and the diff between
both is really only the external IP and the credentials:

# diff vpnc.conf vpnc.conf.old
1,3c1,3
< IPSec gateway 132.174.xxx.xx
< IPSec ID XXXXXXXXXXXX
< IPSec secret XXXXXXXXXX
---
> IPSec gateway 132.174.xxx.xx
> IPSec ID XXXXXXX
> IPSec secret XXXXXXXXX

After the VPN tunnel is established correctly and routings are setup, I
run a PING to the remote DNS server and the pkg are sent to the VPN interface
tun0:

# tcpdump -n -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
13:41:25.906344 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4992, length 64
13:41:26.909180 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4993, length 64
13:41:27.910305 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4994, length 64
13:41:28.916432 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4995, length 64
13:41:29.923030 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4996, length 64
13:41:30.924670 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4997, length 64
13:41:31.931023 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711, seq 4998, length 64

but no answer is coming in;


When I watch at the same time the Internet interface wlan0 of the
laptop, I see the traffic caused by the PING also in the wlan0
interface:

# tcpdump -n -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:43:30.889779 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x11b), length 116
13:43:31.899887 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x11c), length 116
13:43:32.931689 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x11d), length 116
13:43:33.940569 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x11e), length 116
13:43:34.950683 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x11f), length 116
13:43:35.956574 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x120), length 116
13:43:36.958244 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x121), length 116
13:43:37.965300 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x122), length 116
13:43:38.973784 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x123), length 116
13:43:39.985459 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x124), length 116
13:43:41.008307 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x125), length 116
13:43:42.043100 IP 10.42.0.152 > 132.174.XXX.XX: ESP(spi=0x31c98d2c,seq=0x126), length 116

but there is no answer from the concentrator 132.174.XXX.XX.

My colleagues who are using some Windows vpnclient do not face this
problem, i.e. the concentrator and the file xxx.pcf seems to be fine.
They all get an IP addr assigned from the same range 10.31.30.100 ... 10.31.30.102

Any ideas, what could be the problem? I have a longish --debug 3 log if
someone wants to have a look.

Thanks

matthias

--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Re: changes to VPN profile, result: no IP traffic after VPN comes up [ In reply to ]
You're sure that the new DNS server and/or firewall aren't simply blocking
ping packets?

Can your colleagues using Windows reproduce the *exact* same ICMP ping to
the same DNS server and get a response to it?

Dan

On Jul 31, 2018 5:59 AM, "Matthias Apitz" <guru@unixarea.de> wrote:


Hello,

Caused by a dead Cisco 3000 concentrator we got new VPN profiles xxx.pcf
to connect to another concentrator with some other IP and credentials.
Based on the PCF file I created the new vpnc.conf and the diff between
both is really only the external IP and the credentials:

# diff vpnc.conf vpnc.conf.old
1,3c1,3
< IPSec gateway 132.174.xxx.xx
< IPSec ID XXXXXXXXXXXX
< IPSec secret XXXXXXXXXX
---
> IPSec gateway 132.174.xxx.xx
> IPSec ID XXXXXXX
> IPSec secret XXXXXXXXX

After the VPN tunnel is established correctly and routings are setup, I
run a PING to the remote DNS server and the pkg are sent to the VPN
interface
tun0:

# tcpdump -n -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 262144 bytes
13:41:25.906344 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4992, length 64
13:41:26.909180 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4993, length 64
13:41:27.910305 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4994, length 64
13:41:28.916432 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4995, length 64
13:41:29.923030 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4996, length 64
13:41:30.924670 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4997, length 64
13:41:31.931023 IP 10.31.30.102 > 10.23.47.18: ICMP echo request, id 50711,
seq 4998, length 64

but no answer is coming in;


When I watch at the same time the Internet interface wlan0 of the
laptop, I see the traffic caused by the PING also in the wlan0
interface:

# tcpdump -n -i wlan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:43:30.889779 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x11b), length 116
13:43:31.899887 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x11c), length 116
13:43:32.931689 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x11d), length 116
13:43:33.940569 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x11e), length 116
13:43:34.950683 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x11f), length 116
13:43:35.956574 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x120), length 116
13:43:36.958244 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x121), length 116
13:43:37.965300 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x122), length 116
13:43:38.973784 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x123), length 116
13:43:39.985459 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x124), length 116
13:43:41.008307 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x125), length 116
13:43:42.043100 IP 10.42.0.152 > 132.174.XXX.XX:
ESP(spi=0x31c98d2c,seq=0x126), length 116

but there is no answer from the concentrator 132.174.XXX.XX.

My colleagues who are using some Windows vpnclient do not face this
problem, i.e. the concentrator and the file xxx.pcf seems to be fine.
They all get an IP addr assigned from the same range 10.31.30.100 ...
10.31.30.102

Any ideas, what could be the problem? I have a longish --debug 3 log if
someone wants to have a look.

Thanks

matthias

--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: changes to VPN profile, result: no IP traffic after VPN comes up [ In reply to ]
El día martes, julio 31, 2018 a las 06:56:25a. m. -0700, Daniel Lenski escribió:

> You're sure that the new DNS server and/or firewall aren't simply blocking
> ping packets?

I used PING when I realized that DNS queries to port 53 of the DNS
server aren't replied to either.


> Can your colleagues using Windows reproduce the *exact* same ICMP ping to
> the same DNS server and get a response to it?

I have asked them and will forward what they reply.

Meanwhile, I realized that there is some change of the IP level to the
new concentrator. I found out that when I not disable my local firewall
(ipf of FreeBSD) completely, what I of course did when the problem
showed up, I have to add new rules. If I don't do so, some traffic gets
blocked:

# Allow outgoing IPSec
#
pass out log first quick on wlan0 proto udp from any to any port = 500 keep state
pass out log first quick on wlan0 proto udp from any to any port = 10000 keep state

# these rules are new:

pass out log first quick on wlan0 proto udp from any to any port = 4500 keep state
pass out log first quick on wlan0 proto esp from any to any keep state

If the line about 'esp' is not there, this traffic gets blocked:

Jul 31 11:34:53 c720-r314251 ipmon[688]: 11:34:53.626693 wlan0 @0:45 b 10.42.0.152 -> 132.174.xxx.xx PR esp len 20 (128) OUT

The line about port 4500 I have added because one of the Windows
colleagues claimed that in his GUI the port 4500 is shown as the UDP
transport layer.

But, this is a side note, because as I said, I disabled the firewall
completely for the (failing) tests.

matthias

--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
_______________________________________________
vpnc-devel mailing list
vpnc-devel@unix-ag.uni-kl.de
https://lists.unix-ag.uni-kl.de/mailman/listinfo/vpnc-devel
http://www.unix-ag.uni-kl.de/~massar/vpnc/
Re: changes to VPN profile, result: no IP traffic after VPN comes up [ In reply to ]
On Tue, Jul 31, 2018 at 10:35 AM, Matthias Apitz <guru@unixarea.de> wrote:
> El día martes, julio 31, 2018 a las 06:56:25a. m. -0700, Daniel Lenski
escribió:
>
>> You're sure that the new DNS server and/or firewall aren't simply
blocking
>> ping packets?
>
> I used PING when I realized that DNS queries to port 53 of the DNS
> server aren't replied to either.
>
>
>> Can your colleagues using Windows reproduce the *exact* same ICMP ping to
>> the same DNS server and get a response to it?
>
> I have asked them and will forward what they reply.
>
> Meanwhile, I realized that there is some change of the IP level to the
> new concentrator. I found out that when I not disable my local firewall
> (ipf of FreeBSD) completely, what I of course did when the problem
> showed up, I have to add new rules. If I don't do so, some traffic gets
> blocked:

I'm a bit confused. Are you saying that with a certain local firewall
configuration, *some traffic* does go to the VPN?

> The line about port 4500 I have added because one of the Windows
> colleagues claimed that in his GUI the port 4500 is shown as the UDP
> transport layer.

Yes, port 4500 is the standard port for ESP-encapsulated-in-UDP.
https://tools.ietf.org/html/rfc3948#section-2.2 If the old VPN *didn't* use
port 4500, it's likely because it used "raw" ESP-over-IP. Modern ESP
implementations basically always use ESP-over-UDP because it can traverse
(some) NATs.

Are you sure that both your local system and any intermediate firewalls
allow UDP port 4500 traffic in both directions?

You might also want to try `vpnc --local-port 0` to use a random
unprivileged port from the client side.

Dan
Re: changes to VPN profile, result: no IP traffic after VPN comes up [ In reply to ]
El día martes, julio 31, 2018 a las 09:29:21p. m. -0700, Daniel Lenski escribió:

> On Tue, Jul 31, 2018 at 10:35 AM, Matthias Apitz <guru@unixarea.de> wrote:
> > El día martes, julio 31, 2018 a las 06:56:25a. m. -0700, Daniel Lenski
> escribió:
> >
> >> You're sure that the new DNS server and/or firewall aren't simply
> blocking
> >> ping packets?
> >
> > I used PING when I realized that DNS queries to port 53 of the DNS
> > server aren't replied to either.
> >
> >
> >> Can your colleagues using Windows reproduce the *exact* same ICMP ping to
> >> the same DNS server and get a response to it?
> >
> > I have asked them and will forward what they reply.
> >
> > Meanwhile, I realized that there is some change of the IP level to the
> > new concentrator. I found out that when I not disable my local firewall
> > (ipf of FreeBSD) completely, what I of course did when the problem
> > showed up, I have to add new rules. If I don't do so, some traffic gets
> > blocked:
>
> I'm a bit confused. Are you saying that with a certain local firewall
> configuration, *some traffic* does go to the VPN?

No! With the firewall enabled a *saw* that the ESP traffic was blocked
by the final general rule.

For the rest see the other mail I've sent some minutes ago.

matthias



--
Matthias Apitz, ? guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: ???????? ????????????! Thank you very much, Russian liberators!