LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 01-23-2012, 08:29 PM   #1
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Rep: Reputation: Disabled
Routing Problem, Ugh!


Hello all,

I have a slight routing problem. From my machine at work I connect to various customer networks and all of them are on different RFC 1918 networks. I have two gateways at work:

192.168.1.1 which is my default gateway and is used for all of my NON RFC1918 communication (ie. internet traffic).
172.31.1.1 which is a VPN concentrator that all of the customer tunnels are built to.

Here are the routes I have setup:

Code:
$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.1.1.110      192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     192.168.1.1     255.255.255.0   UG    0      0        0 eth0
192.168.0.0     172.31.1.1      255.255.0.0     UG    0      0        0 eth0.102
172.16.0.0      172.31.1.1      255.240.0.0     UG    0      0        0 eth0.102
10.0.0.0        172.31.1.1      255.0.0.0       UG    0      0        0 eth0.102
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
So with these routes, all of my internet traffic (0.0.0.0/0) goes to 192.168.1.1 and all of my RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) traffic goes to 172.31.1.1. This works perfectly and I am able to connect to our client's equipment just fine, and all of my web surfing, etc is properly routed out the company firewall.

Now, to complicate matters my own VPN tunnel is built to the 192.168.1.1 device (it also has a public IP, for outside employee-only VPN) the problem arises when I attempt to SSH to my work machine (we'll call it 192.168.1.200) from the VPN tunnel from my home computer or anywhere else, the problem occurs because my computer at home is, of course, on it's own network (10.1.1.0/24 in this case) and so when I SSH in from the VPN traffic comes into my work machine on the eth0 interface from the 192.168.1.1 firewall but return traffic is directed out the 172.31.1.1 interface which is incorrect... not only does 172.31.1.1 have no idea about my VPN tunnel any stateful inspection would fail since that device is only seeing the return traffic.

The only way I can make this work is to add a host route (the first route from the table above) so that return traffic to my home machine is properly routed out the eth0 interface to the 192.168.1.1 firewall. This is a working fix for my home machine which never has any other IP other than 10.1.1.110 but if I am connecting from a friends house or from a coffee shop this obviously doesn't work since I will almost never have the 10.1.1.110 IP from there.

What I would like to do is the following:
A) Use routes from the table above UNLESS:
B) The traffic originates on the eth0 interface, in which case send any return traffic back out that interface and:
C) Only use the 172.31.1.1 gateway on the eth0.102 interface for traffic *originating* from my machine.

This way any new connections I make from my work machine to any 10., 172.16-31, or 192.168 will go out the eth0.102 interface yet any connections that sourced from eth0 will still work, even if they fall within the aformentioned ranges.

Any help with this would be greatly appreciated!

EDIT: I *think* iproute2 would help with this but I cannot for the life of my figure it out.

Thanks,
Brandon

Last edited by Malaphus; 01-23-2012 at 08:30 PM.
 
Old 01-24-2012, 07:24 AM   #2
amilo
Member
 
Registered: Oct 2011
Location: Nederland
Distribution: Debian, Centos, Ubuntu
Posts: 80

Rep: Reputation: Disabled
Perhaps in this document is the answer.
http://lartc.org/howto/
 
Old 01-24-2012, 07:07 PM   #3
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Thanks for the reply Amilo. However I am just not understanding this. I have created a new routing table called CORP with one entry:

$ sudo ip route list table CORP
default via 192.168.2.1 dev eth0

and I have created a policy rule as follows:

$ sudo ip rule list
0: from all lookup local
32765: from all iif eth0 lookup CORP
32766: from all lookup main
32767: from all lookup default


So it seems to me that traffic coming from eth0 should match the 32765 rule and be checked against the CORP table, however for some reason traffic is still trying to return using the main routing table.
 
Old 01-26-2012, 10:26 AM   #4
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Does anyone else have any ideas how I can make this work, possible with an example? This is driving me crazy.

Thanks in advance,
Brandon
 
Old 01-26-2012, 11:04 AM   #5
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 593

Rep: Reputation: 62
1st off, the term "originates from" means nothing unless you define the protocol. all frames that leave your iface have a src mac of that iface, hence, they all "originate" from that iface.

unfortunately, tracking "origination" will break for protocols like udp since it is a stateless protocol.

the solution is to NAT the ingres vpn traffic (src IP) to a pool of unused IP. since in your case you have used the 10's 192.168's and 172.16's to goto the concentrator, pick a reserved ip block thats listed in iana (like something in 250/8, maybe 250.5.5.0/24, etc). so not to have to add routing to all your internal hosts, just add routes to the gateways to route this new ip block back to the system that was doing the vpn for your home machine, this guarantees egres gets back to the ingres vpn device, etc.

the key to vpn success is to make sure ingres has same egres point and vice-versa. if your vpn device cannot support a NAT'ing function then you need to stick a NAT capable device between the vpn device and your lan, etc.

Last edited by Linux_Kidd; 01-26-2012 at 11:15 AM.
 
1 members found this post helpful.
Old 01-26-2012, 11:56 AM   #6
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Linux_Kidd View Post
1st off, the term "originates from" means nothing unless you define the protocol. all frames that leave your iface have a src mac of that iface, hence, they all "originate" from that iface.

unfortunately, tracking "origination" will break for protocols like udp since it is a stateless protocol.

the solution is to NAT the ingres vpn traffic (src IP) to a pool of unused IP. since in your case you have used the 10's 192.168's and 172.16's to goto the concentrator, pick a reserved ip block thats listed in iana (like something in 250/8, maybe 250.5.5.0/24, etc). so not to have to add routing to all your internal hosts, just add routes to the gateways to route this new ip block back to the system that was doing the vpn for your home machine, this guarantees egres gets back to the ingres vpn device, etc.

the key to vpn success is to make sure ingres has same egres point and vice-versa. if your vpn device cannot support a NAT'ing function then you need to stick a NAT capable device between the vpn device and your lan, etc.
Thanks Linux_Kidd, one more question: If I take the VPN stuff out of the loop I have the following:

2 networks at work: 192.168.1.x and 172.31.1.x. Given the routes I listed above if I, say, ssh to one of the 172.31.1.x machines the traffic is routed out the 172.31.1.1 gateway appropriately and I can establish a connection. That remote machine can also SSH to my machine's 172.31.1.x address (vlan 102, interface eth0.102). However, if that remote machine SSH's to my machine's 192.168.1.x address the connection hangs and is never established, I think this happens because the connection comes into my machine over eth0 (192.168.1.x/24) but tries to go back out 172.31.1.x, based on the routes I have setup. Is there any way for me to get around this and have traffic coming from 172.31.1.x/24 yet over eth0 to go BACK out over eth0 as well, instead of eth0.102?

Thanks again,
Brandon
 
Old 01-26-2012, 12:46 PM   #7
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 593

Rep: Reputation: 62
i am guessing asymmetric routing is the issue. the ssh server has no way to route packets to 172 subnet when they come in on the 192.168 side.

what does your ifconfig -a look like?
eth0 has ip in 192.168.1/24
and eth0.102 has ip in 172.16.31/24
is this correct?

with forwarding turned off the packets cannot cross over to the other iface.
try editing your /etc/sysctl.conf

# Controls IP packet forwarding, 1=on 0=off
net.ipv4.ip_forward = 1

why do you have this route??? your box has an IP in that subnet, this route looks like its not needed. you dont route packets destined to the local subnet, local packets will be forwarded via layer-2, etc.
Code:
192.168.1.0     192.168.1.1     255.255.255.0   UG    0      0        0 eth0


and where are the local subnet routes?

my rhel5 route table looks like this (single nic single IP, local subnet in red, etc)
Code:
[root@host]$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.218.0.0      *               255.255.254.0   U         0 0          0 eth0
default         10.218.1.0      0.0.0.0         UG        0 0          0 eth0

Last edited by Linux_Kidd; 01-26-2012 at 02:46 PM.
 
Old 01-27-2012, 09:55 AM   #8
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Yes you are correct about my interfaces. I have enabled ip_forward (rebooted afterwards) and sysctl does show it as 1 now. Here are my routing tables:

Code:
$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.31.1.0      *               255.255.255.0   U         0 0          0 eth0.102
192.168.1.0     *               255.255.255.0   U         0 0          0 eth0
link-local      *               255.255.0.0     U         0 0          0 eth0.102
192.168.0.0     172.31.1.1      255.255.0.0     UG        0 0          0 eth0.102
172.16.0.0      172.31.1.1      255.240.0.0     UG        0 0          0 eth0.102
10.0.0.0        172.31.1.1      255.0.0.0       UG        0 0          0 eth0.102
default         192.168.2.1     0.0.0.0         UG        0 0          0 eth0
I can still SSH to my machine's 172.31.1.100 address from the 172.31.1 network but I cannot SSH to my machine's 192.168.1.100 address from the 172.31.1 network. I'm guessing traffic is still coming in on eth0 (when SSHing to me: 192.168.1.100 from: 172.31.1.whatever) but trying to go out the eth0.102 interface, and so it's failing since it's coming from a different IP.
 
Old 01-27-2012, 11:52 AM   #9
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 593

Rep: Reputation: 62
i need to look closer, but why did your default gateway change from 1.1 to 2.1 ???

do you have any tcpdump's of this connection?

on the ssh client machine (the 172. client) what does routing look like on that host??

can you give output of traceroute for server-to-host and host-to-server.

Last edited by Linux_Kidd; 01-27-2012 at 11:55 AM.
 
Old 01-27-2012, 02:19 PM   #10
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Sorry that 2 was a typo on my part in an attempt to obscure my actual IPs (not that it matters I guess since they are private). It should have actually been a 1, and it's correct in my actual routing table.

As for traceroutes:
- When doing a trace from my machine to a machine on the 172.31.1.x network it's only 1 hop directly to the machine (since it's using my eth0.102 interface).
- When doing a trace from the 172.31.1.x network machine to my machine's 172.31.1.100 address it goes first to the 172.31.1.1 router (that's the default gateway on that machine), then to my machine.
- When doing a trace from the 172.31.1.x network machine to my machine's 192.168.1.100 address it makes it to the default gateway (172.31.1.1) but dies after that.

I do not have tcpdumps at the moment but will try to get some.
 
Old 01-27-2012, 04:41 PM   #11
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 593

Rep: Reputation: 62
1. the 2nd traceroute makes no sense. a packet src'd from 172.31.1.x going to a host on the same local subnet 172.31.1.100 should not be routed, it should be layer-2 forwarded directly to the host, so you'll need to explain that.

2. does the 172.31.1.1 "box" have a iface on the 192.168.1.0/24 subnet, or has a route to another hop that does?? if not then how would a packet get to 192.168.1/24 from itself??

we need the route tables for all 3 devices, and, tcpdump's from the ssh server while you try your connection scenarios, etc. seems like your routing is whacked or some devices dont have any way to move the packets, etc.
 
Old 01-27-2012, 08:15 PM   #12
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Actually you are right, I am not sure what I was thinking. Here are the traceroutes:

From random machine on 172.31.1.x network, tracerouting to my machine's 172 address:

Code:
remotemachine$ traceroute 172.31.1.100
traceroute to 172.31.1.100 (172.31.1.100), 30 hops max, 60 byte packets
 1  mymachine (172.31.1.100)  0.275 ms  0.254 ms  0.238 ms
remotemachine$
From random machine on 172.31.1.x network, tracerouting to my machine's 192 address:

Code:
remotemachine$ traceroute 192.168.1.100
traceroute to 192.168.1.100 (192.168.1.100), 30 hops max, 60 byte packets
 1  172.31.1.1 (172.31.1.1)  0.860 ms  0.985 ms  1.105 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 (repeat 25 more times)
remotemachine$
When I traceroute from my machine to the random 172 machine, the traceroute obviously works and goes right to the destination since it's using my eth0.102 interface:

Code:
mymachine$ traceroute 172.31.1.103
traceroute to 172.31.1.103 (172.31.1.103), 30 hops max, 60 byte packets
 1  remotemachine (172.31.1.103)  0.263 ms  0.254 ms  0.243 ms
mymachine$
When I ifdown my eth0.102 interface and ensure there are no 172.31.1 routes, my traceroute to the remote machine still works:

Code:
mymachine$ sudo ifdown eth0.102
Removed VLAN -:eth0.102:-
mymachine$ traceroute 172.31.1.103
traceroute to 172.31.1.103 (172.31.1.103), 30 hops max, 60 byte packets
 1  remotemachine (172.31.1.103)  0.501 ms  0.489 ms  0.486 ms
mymachine$
With eth0.102 down on my machine I can successfully SSH to my machine's 192 address from the random 172 machine, if I ifup the eth0.102 interface on my machine and try to SSH into it again from the random machine, SSH fails.

Last edited by Malaphus; 01-27-2012 at 10:29 PM.
 
Old 01-27-2012, 08:18 PM   #13
Malaphus
LQ Newbie
 
Registered: Jul 2011
Location: Charlotte, NC
Distribution: Debian, BSD
Posts: 13

Original Poster
Rep: Reputation: Disabled
Oh, here are the routing tables on both machines:

Code:
remotemachine$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.31.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         172.31.1.1      0.0.0.0         UG        0 0          0 eth0
remotemachine$
Code:
mymachine$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.31.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0.102
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.0.0     172.31.1.1      255.255.0.0     UG        0 0          0 eth0.102
172.16.0.0      172.31.1.1      255.240.0.0     UG        0 0          0 eth0.102
10.0.0.0        172.31.1.1      255.0.0.0       UG        0 0          0 eth0.102
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
mymachine$
 
Old 01-27-2012, 09:34 PM   #14
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 593

Rep: Reputation: 62
you created a vlan iface? take a look at this article
http://www.cyberciti.biz/tips/howto-...work-vlan.html
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Ugh, Frustrated. wh33t Linux - Newbie 13 01-09-2012 06:10 PM
ugh porkcharsui Linux - Newbie 1 02-11-2011 07:11 AM
Wireless (Ugh, Yes I know...) Drunken Pirate Slackware 5 07-15-2006 07:47 PM
Ugh, so frustrated with this... RoaCh Of DisCor Linux - Software 8 04-01-2005 01:47 PM
Ugh...Can't mount CD tubatodd Slackware 21 07-09-2004 08:10 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 03:29 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration