[Solved] - Dual homed server does not talk to VPN

[Solved] - Dual homed server does not talk to VPN

Postby linuxdad » Feb 17th, '15, 00:40

What is the issue with a Dual homed Server which has the Default Route which points to the external network.

The Routing info looks like:

Code: Select all
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         X.X.X.225  0.0.0.0         UG        0 0          0 eno1
X.X.X.224  0.0.0.0         255.255.255.240 U         0 0          0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eno1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eno2
192.168.50.0    0.0.0.0         255.255.255.0   U         0 0          0 eno2



Eno1 is the external interface, eno2 is the internal interface. The VPN connects on 192.168.50.1 unfortunately when I connect through the VPN, I cannot get the webserver to talk back.
Last edited by linuxdad on Mar 1st, '15, 17:24, edited 1 time in total.
Albert E. Whale, CEH CHS CISA CISSP
President - Chief Security Officer
IT Security, Inc. - http://www.IT-Security-inc.com
Pittsburgh, PA
Email: Albert.Whale@IT-Security-inc.com
linuxdad
 
Posts: 123
Joined: Nov 17th, '13, 21:14

Re: Dual homed server does not talk to VPN

Postby wintpe » Feb 20th, '15, 18:47

im not 100% sure ive understood your requirements, so im going to have to guess, apologies if ive got it wrong.

you have a host thats acting as a gateway and vpn server.

it has two nics, one for the vpn to come into (external), and one that the webserver is connected to (dmz or internal)

and a host that is using vpn to connect into 192.168.1.50 cant reach the webserver hanging off the internal interface.

if this is the case, and the reason i think it is is im using exactly the same setup for my mail server,

then adding iptables masquerading to the server with two interfaces on the vpn's incoming interface

means that packets originating from a pc on the other end of the vpn will look like they are coming from the dual homed host, and
will eliminate multihop routing to and from the webserver.

and as masquerading keeps connection tracking, the packets will get rewritten on the way back.

its the simplest way to implement a vpn from say a 3g connection back home through your adsl , through your firewall into a vpn host and gain access to your internal systems, without having a route defined for each destination back via the multihomed host for packets destined for the workstation out on 3g/public wireless access.

ill attempt a horrible diagram, it may not be 100% accurate, but the only way i can describe it.

the bit in bold is the vpn tunnel

web browser -->> into tun0(10.0.0.8) >>>3g/wireless -> out through internet through your isp into adsl --> into firewall --->>> into vpn server ---> tun0 packet exists tun0, heads off to destination -->> internal network -->> webserver ---> reaches destination
webserver tries to return packet to 10.0.0.8 but cant find a route back, so hangs.

add route back through multihomed host, then on mutihomed host add a route back on tun0.

or

if packet gets rewritten on multihomed host through mascurading then when it arrives at webserver, webserver returns to mutihomehost which it already knows as they are on the same network.

when the packet hits network stack and ipfilter its matched against mascuradings tracking table and sent back through tun0 to original host.


regards peter
Redhat 6 Certified Engineer (RHCE)
Sometimes my posts will sound short, or snappy, however its realy not my intention to offend, so accept my apologies in advance.
wintpe
 
Posts: 1204
Joined: May 22nd, '11, 17:08
Location: Rayleigh,, Essex , UK

Re: Dual homed server does not talk to VPN

Postby linuxdad » Mar 1st, '15, 17:24

Thanks Peter,

Your reply did not hit me right away, until I attempted to reconnect again with the VPN, and I noticed that my LAN setting was not in the same network as the internal network interface. The VPN Connection was on the 192.168.49.0 subnet.

Thank you very much! My problems will be resolved when I include either a Class C subnet reference in the routing table, or a Class B Network to permit for future expansion.
Albert E. Whale, CEH CHS CISA CISSP
President - Chief Security Officer
IT Security, Inc. - http://www.IT-Security-inc.com
Pittsburgh, PA
Email: Albert.Whale@IT-Security-inc.com
linuxdad
 
Posts: 123
Joined: Nov 17th, '13, 21:14


Return to Networking

Who is online

Users browsing this forum: No registered users and 1 guest

cron