Lost packets through the virtual switch / Next hope occurs

Post your questions about SoftEther VPN software here. Please answer questions if you can afford.
Post Reply
jerume
Posts: 11
Joined: Fri Dec 06, 2013 12:05 pm

Lost packets through the virtual switch / Next hope occurs

Post by jerume » Thu Dec 19, 2013 7:23 am

Hello,

You will find a drawing there: http://i.imgur.com/LqfP6hs.jpg which explain our network.

FYI :
-> We have huge performances issue and routing issue: 2 lost packets at the beginning of every new tpc/udp/icmp sessions between clients machines through the virtual switch ( cause from a strange routing behaviors on the system side? ).
-> The IP address on the drawing are fake ones. Let say we have the right to take 172.0/8 ;)
-> Our systems are based on Debian 6 and 7.
-> The network 192.168.10.0/24 in the USA that you will see on the drawing are not intended to be reached by UK.

What I can do :

Ping the physical IP interface of the VPN Bridge's server 172.37.0.254 from a client machine in the USA
Ping the physical IP interface of the VPN Server's server 172.30.0.223 from a client machine in the UK ( VLAN 30,32,33 ).
Get access from a client machine in UK ( VLAN 30,32,33 ) to a client machine in USA.
Get access from a client machine in USA to a client machine in UK ( VLAN 30,32,33 ).
Ping the virtual IP 172.37.7.254 ( Virtual IP for USA HUB on SE Virtual Switch in UK ) from a client machine in USA or from a client machine in UK ( VLAN 30,32,33 ).
Ping the virtual IP 172.30.7.254 ( Virtual IP for UK HUB on SE Virtual Switch in UK ) from a client machine in USA or from a client machine in UK ( VLAN 30,32,33 ).



What I can’t do :
Ping the physical IP interface of the VPN Server's server 172.30.0.223 from a client machine in the USA or from the « VPN Bridge » server itself. (1)
Ping the physical IP interface of the VPN Bridge's server 172.37.0.254 from a client machine in UK or from the « VPN Server » server itself. (2)
Ping the virtual IP interface for USA HUB on SE Virtual Switch in UK 172.37.7.254 from the server "VPN Bridge" server in USA or « VPN Server" server in UK.
Ping the virtual IP interface for UK HUB on SE Virtual Switch in UK 172.30.7.254 from the server "VPN Bridge" server in USA or « VPN Server" server in UK.

(1) & (2) are very annoying as I can SSH to the VPN Bridge server (in USA) from an US machine only or by its public IP.

Furthermore and that is related I think, I have 2 lost packets at the beginning of a each new communication between two client hosts( one in USA, one in UK ). Which is very strange:

2:10 root@work54.USA ~ # ping 172.30.7.254 [That's in UK]
From 172.37.0.254 [Physical IP for SE VPN Bridge's server in USA, aka the gateway]: icmp_seq=2 Redirect Host(New nexthop: 172.37.7.254 [Virtual IP for USA HUB on SE Virtual Switch in UK])

An ip route on the SE VPN Bridge's server gives :
172.37.0.0/21 dev eth0 proto kernel scope link src 172.37.0.254
172.30.0.0/21 via 172.37.7.254 dev eth0


Example :
First try :

work22.usa:~# ping edge96.uk
PING edge96.uk (172.30.0.146) 56(84) bytes of data.
From vpnbridgeserver.usa (172.37.0.254) icmp_seq=1 Destination Host Unreachable
From vpnbridgeserver.usa (172.37.0.254): icmp_seq=2 Redirect Host(New nexthop: 172.37.7.254)
64 bytes from edge96.uk (172.30.0.146): icmp_req=3 ttl=62 time=90.7 ms
64 bytes from edge96.uk (172.30.0.146): icmp_req=4 ttl=62 time=85.9 ms
^C
— edge96.uk ping statistics ---
4 packets transmitted, 2 received, +1 errors, 50% packet loss, time 2999ms
rtt min/avg/max/mdev = 85.901/88.317/90.734/2.434 ms

Second try, made right after the first :

work22.usa:~# ping edge96.uk
PING edge96.uk (172.30.0.146) 56(84) bytes of data.
64 bytes from edge96.uk (172.30.0.146): icmp_req=1 ttl=62 time=86.0 ms
64 bytes from edge96.uk (172.30.0.146): icmp_req=2 ttl=62 time=85.9 ms
^C
--- edge96.uk ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 85.919/85.975/86.032/0.298 ms

As a consequence, all new SSH connection failed, you have to try 2,3,4 times consecutively before the SSH makes it. All protocol used between USA and UK are impacted, the user experience is bad.

Any ideas guys, please?

Post Reply