Hi,
I have problems where ip packets get silently lost.
I run a vserver that acts as a webserver and vpn server. Two clients
have a vpn tunnel to this server.
The vpn interfaces of the vserver are using the same ip but are not bridged.
The vpn interface of the clients are using an private ip from the same ip range.
The gateway vpn connection between client1 and client2 are using an ip from different range.
All interfaces are nat-ed.
Code:
....................................
. XEN - VSERVER .
. .
Client1=(10.12.10.1) ==== VPN-tunnel 1 via Internet === .tap0:(10.12.0.1) .
(172.16.10.1) . | .
|| . | .
|| . | .
vpn tunnel (gateway vpn) . routing .
|| . | .
|| . | .
(172.16.23.1) . | .
Client2=(10.12.23.1) ==== VPN-tunnel 2 via Internet === .tap1:(10.12.0.1) .
| . .
+-inet:ip1------- direct internet connection --- .eth0 (inet ip2) - Webserver .
....................................
Packet traveling:
- Client 1 sends www-request to client2 via "gateway vpn"
- client 2 forwards www-request to vserver webserver via internet
- vserver sends answer back to client2
- client 2 forwards answer via VPN-tunnel 2 to tap1
At this point the answer packets gets lost
the packet should travel further:
- vserver gets the answer packet and forwards it to the tap0 (target ip is 10.12.10.1)
this is confirmed while sniffing the incomming packet tap1
The source IP of this answer packets is the public internet ip of the webserver (ip2).
- client1 gets the answer via vpn tunnel.
Addtional tests I have made and wich are woring:
- if I access a differnt webserver that does not run on the same vserver, the packet is routed
correctly through the vserver from vpn
- if I send icmp packets directly from client2 via vserver to client1, the packet is routed
correctly
Note that I have to use this routing via vserver and the vpn-tunnel1/2 to avoid extra NAT
on the gateway-vpn. If I use the gateway-vpn for the answer from the webserver, all other
internet traffic will also be NATed on the weak routers. I will get an overload and the
speed drops.
The vpn packets that builds the gateway-vpn tunnel are traveling already via the vpn tunnels
between clients and vserver. but this is no problem, because this is a simble packet path
client1 <-> vserver <-> client2
My assumption is that the kernel sees the answer packet on tap1 that it has created by
itself and sent it via eth0.
I think that there is some kind of loop detection that silencely drops such packets.
But the answer packets does not contain the same target ip adresse. The webserver
sends its answer to a public ip adresse of client2 (ip1) with its source ip set to ip2.
My question:
is there any way to get such a packet forwarded.
is there any /proc switch that disables such a loop detection
I have no way to rebuild this xen-verver kernel (it is hosted by a provider)
Also kernel modules are not a good idea because the provider sometimes updates
the kernel and then the modules might not work anymore.
/Stephan
