Client to client acces only after PING

Need help configuring your VPN? Just post here and you'll get that help.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
markubi
OpenVpn Newbie
Posts: 1
Joined: Tue Nov 05, 2013 12:52 pm

Client to client acces only after PING

Post by markubi » Tue Nov 05, 2013 1:08 pm

Hello,
I migrate our openVPN server from firewall/router/gateway PC (10.0.0.1) to another PC (10.0.0.6) in our local LAN.

On Firewall PC was static route added 172.16.0.0/255.255.255.0/gw 10.0.0.6

After migration can vpn clients connect to VPN server without problems.
BUT they can PING and ACCESS only VPNserver (10.0.0.6) and Firewall/router (10.0.0.1)

So I try to ping from my LAN pc (10.0.0.130) to some actually connected VPN client (172.16.0.6), and PING is working!
AND after that first "LAN to VPN" ping, I can ping (and access) from VPN client (172.16.0.6) to my LAN PC (10.0.0.130) "forever".

So CLIENT to CLIENT access/comunication is working only if I first PING from LAN to VPN.

Can somebody help me, what is wrong?

Here is my server config

Code: Select all

local 10.0.0.6
port 5001
proto udp
dev tun
dev-node OpenVPN

ca "c:\\Program Files\\OpenVPN\\keys\\ca.crt"
cert "c:\\Program Files\\OpenVPN\\keys\\server.crt"
key "c:\\Program Files\\OpenVPN\\keys\\server.key"
dh "c:\\Program Files\\OpenVPN\\keys\\dh1024.pem"

server 172.16.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 10.0.0.0 255.0.0.0"
;push "redirect-gateway"

push "dhcp-option DNS 10.0.0.2"
client-to-client
;duplicate-cn
keepalive 10 120
comp-lzo
;max-clients 100
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
log-append  openvpn.log
verb 3
;mute 20


eekay
OpenVpn Newbie
Posts: 14
Joined: Thu May 29, 2014 4:05 pm

Re: Client to client acces only after PING

Post by eekay » Mon Apr 27, 2015 8:33 pm

I'm actually having a somewhat identical issue. However, it is not only client-to-client VPN connections that this happens on. It's all machines on the LAN (besides the VPN server and the router/gateway). The VPN client connects fine and I can access the LAN without any issues but only after I ping the system I wish to connect. For example:

user@system1> ssh test.domain.tld
(after about 60 seconds...)
ssh: connect to host test.domain.tld port 22: Connection timed out

Immediately after:
user@system1> ping -c 3 test.domain.tld
PING test (192.168.1.18) 56(84) bytes of data.
64 bytes from test (192.168.1.18): icmp_seq=1 ttl=62 time=35.8 ms
64 bytes from test (192.168.1.18): icmp_seq=2 ttl=63 time=35.4 ms
64 bytes from test (192.168.1.18): icmp_seq=3 ttl=63 time=34.9 ms

--- test ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 34.924/35.419/35.881/0.391 ms

And then:
user@system1> ssh test.domain.tld
user@system2>

It logs in immediately. Has anyone seen this before? I'm assuming it's related to ARP tables and/or the gateway but I'm not sure where to begin as the tcpdump output on the server doesn't provide much information (that I'm aware of, anyhow...)

Thanks in advance!

eekay
OpenVpn Newbie
Posts: 14
Joined: Thu May 29, 2014 4:05 pm

Re: Client to client acces only after PING

Post by eekay » Tue Apr 28, 2015 2:59 pm

In case it might help, I've supplied the tcpdump output from the server and also from the system I'm trying to connect to (test.domain.tld) below. Trying to connect to port 80 on test.domain.tld from the client before ping.

Server VPN interface:
# tcpdump -n -i tun0 port 80
08:41:28.860783 IP 10.10.9.9.58039 > 192.168.1.18.80: Flags [S], seq 357569663, win 29200, options [mss 1368,sackOK,TS val 319149 ecr 0,nop,wscale 7], length 0
08:41:29.858293 IP 10.10.9.9.58039 > 192.168.1.18.80: Flags [S], seq 357569663, win 29200, options [mss 1368,sackOK,TS val 319399 ecr 0,nop,wscale 7], length 0
08:41:31.862220 IP 10.10.9.9.58039 > 192.168.1.18.80: Flags [S], seq 357569663, win 29200, options [mss 1368,sackOK,TS val 319900 ecr 0,nop,wscale 7], length 0
08:41:35.870279 IP 10.10.9.9.58039 > 192.168.1.18.80: Flags [S], seq 357569663, win 29200, options [mss 1368,sackOK,TS val 320902 ecr 0,nop,wscale 7], length 0
08:41:43.878157 IP 10.10.9.9.58039 > 192.168.1.18.80: Flags [S], seq 357569663, win 29200, options [mss 1368,sackOK,TS val 322904 ecr 0,nop,wscale 7], length 0

Server LAN interface:
# tcpdump -n -i em0 port 80
08:44:11.322145 IP 10.10.9.9.58059 > 192.168.1.18.80: Flags [S], seq 3114136989, win 29200, options [mss 1368,sackOK,TS val 359765 ecr 0,nop,wscale 7], length 0
08:44:12.322054 IP 10.10.9.9.58059 > 192.168.1.18.80: Flags [S], seq 3114136989, win 29200, options [mss 1368,sackOK,TS val 360015 ecr 0,nop,wscale 7], length 0
08:44:14.326194 IP 10.10.9.9.58059 > 192.168.1.18.80: Flags [S], seq 3114136989, win 29200, options [mss 1368,sackOK,TS val 360516 ecr 0,nop,wscale 7], length 0
08:44:18.334067 IP 10.10.9.9.58059 > 192.168.1.18.80: Flags [S], seq 3114136989, win 29200, options [mss 1368,sackOK,TS val 361518 ecr 0,nop,wscale 7], length 0
08:44:26.342044 IP 10.10.9.9.58059 > 192.168.1.18.80: Flags [S], seq 3114136989, win 29200, options [mss 1368,sackOK,TS val 363520 ecr 0,nop,wscale 7], length 0

Test system LAN interface:
07:46:17.147231 IP 10.10.9.9.58066 > 192.168.1.18.80: Flags [S], seq 3862481909, win 29200, options [mss 1368,sackOK,TS val 391221 ecr 0,nop,wscale 7], length 0
07:46:17.147298 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 391221], length 0
07:46:18.146182 IP 10.10.9.9.58066 > 192.168.1.18.80: Flags [S], seq 3862481909, win 29200, options [mss 1368,sackOK,TS val 391471 ecr 0,nop,wscale 7], length 0
07:46:18.146231 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 391471], length 0
07:46:20.150906 IP 10.10.9.9.58066 > 192.168.1.18.80: Flags [S], seq 3862481909, win 29200, options [mss 1368,sackOK,TS val 391972 ecr 0,nop,wscale 7], length 0
07:46:20.150975 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 391972], length 0
07:46:23.199938 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 391972], length 0
07:46:24.159045 IP 10.10.9.9.58066 > 192.168.1.18.80: Flags [S], seq 3862481909, win 29200, options [mss 1368,sackOK,TS val 392974 ecr 0,nop,wscale 7], length 0
07:46:24.159096 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 392974], length 0
07:46:27.176076 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 392974], length 0
07:46:30.198414 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 392974], length 0
07:46:32.166639 IP 10.10.9.9.58066 > 192.168.1.18.80: Flags [S], seq 3862481909, win 29200, options [mss 1368,sackOK,TS val 394976 ecr 0,nop,wscale 7], length 0
07:46:32.166691 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 394976], length 0
07:46:35.182939 IP 192.168.1.18.80 > 10.10.9.9.58066: Flags [S.], seq 1656694809, ack 3862481910, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 1718510613 ecr 394976], length 0

Gateway LAN interface:
08:51:50.669723 IP 192.168.1.18.80 > 10.10.9.9.58117: Flags [S.], seq 2644444646, ack 75301707, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 2527065738 ecr 472340], length 0
08:51:59.407253 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 476785], length 0
08:52:00.404186 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 477035], length 0
08:52:02.408171 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 477536], length 0
08:52:05.410714 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 477536], length 0
08:52:06.416142 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 478538], length 0
08:52:09.434051 IP 192.168.1.18.80 > 10.10.9.9.58120: Flags [S.], seq 935091276, ack 3731772220, win 65535, options [mss 1368,nop,wscale 6,sackOK,TS val 4068713624 ecr 478538], length 0

It looks like everything on the LAN side is working correctly, doesn't it? Almost like the VPN client isn't accepting packets from the LAN for some reason. However, once I ping the test.domain.tld server, everything flows completely normal...

User avatar
maikcat
Forum Team
Posts: 4200
Joined: Wed Jan 12, 2011 9:23 am
Location: Athens,Greece
Contact:

Re: Client to client acces only after PING

Post by maikcat » Wed Apr 29, 2015 11:37 am

On Firewall PC was static route added 172.16.0.0/255.255.255.0/gw 10.0.0.6
can you try add this static route to a pc directly?

Michael.

eekay
OpenVpn Newbie
Posts: 14
Joined: Thu May 29, 2014 4:05 pm

Re: Client to client acces only after PING

Post by eekay » Sat May 02, 2015 3:35 pm

Hi maikcat,

I have tried this and it works without any issues at all. No need to ping the destination before I connect with a static route on the system. However, I would have to do this to every workstation and server on the LAN which would be quite time consuming. Also, as workstations and servers change, it would be difficult to keep up with. So, it would be nice to come up with a resolution that fixes this issue at the proper level. I'll keep digging into the server and gateway/router configurations to see if I can come up with anything.

Post Reply