Is it possible to have a route stick in the kernel, even if device it points to goes to roller coaster up and down drive.
For example. I have an ADSL modem and am doing VPN over it. There's a route needed for VPN added like this:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
There are two problems with it:
a) if ADSL link is down when above command is executed, the route command will fail (ppp0 is down, so there's no 1.2.3.4)
b) if ADSL link is up when above command is executed, but it goes down (and up again) later, the route is removed from kernel routing tables
So, if there are any problems with ADSL link, I need to manually reset my VPN setup.
I could write some monitoring script (and call it from cron) that would check if route is present and attempt to readd it if needed, but I'd rather be able to have the route either sticky (not removed when interface goes down) or automatically reenabled by the kernel when interface goes up again.
Thanks, Aleksandar Milivojevic
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Yes, /etc/sysconfig/static-routes
Regards, Dan On Aug 5, 2005, at 8:06 AM, Aleksandar Milivojevic wrote:
Is it possible to have a route stick in the kernel, even if device it points to goes to roller coaster up and down drive.
For example. I have an ADSL modem and am doing VPN over it. There's a route needed for VPN added like this:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
There are two problems with it:
a) if ADSL link is down when above command is executed, the route command will fail (ppp0 is down, so there's no 1.2.3.4)
b) if ADSL link is up when above command is executed, but it goes down (and up again) later, the route is removed from kernel routing tables
So, if there are any problems with ADSL link, I need to manually reset my VPN setup.
I could write some monitoring script (and call it from cron) that would check if route is present and attempt to readd it if needed, but I'd rather be able to have the route either sticky (not removed when interface goes down) or automatically reenabled by the kernel when interface goes up again.
Thanks, Aleksandar Milivojevic
This message was sent using IMP, the Internet Messaging Program.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Also check: /etc/ppp/ip-down.local /etc/ppp/ip-up.local
Dan Gorman wrote:
Yes, /etc/sysconfig/static-routes
Regards, Dan On Aug 5, 2005, at 8:06 AM, Aleksandar Milivojevic wrote:
Is it possible to have a route stick in the kernel, even if device it points to goes to roller coaster up and down drive.
For example. I have an ADSL modem and am doing VPN over it. There's a route needed for VPN added like this:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
There are two problems with it:
a) if ADSL link is down when above command is executed, the route command will fail (ppp0 is down, so there's no 1.2.3.4)
b) if ADSL link is up when above command is executed, but it goes down (and up again) later, the route is removed from kernel routing tables
So, if there are any problems with ADSL link, I need to manually reset my VPN setup.
I could write some monitoring script (and call it from cron) that would check if route is present and attempt to readd it if needed, but I'd rather be able to have the route either sticky (not removed when interface goes down) or automatically reenabled by the kernel when interface goes up again.
Thanks, Aleksandar Milivojevic
This message was sent using IMP, the Internet Messaging Program.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am Fr, den 05.08.2005 schrieb Dan Gorman um 17:12:
/etc/sysconfig/static-routes
Dan
That is device independent only and only read in by the /etc/init.d/network init script. So it falls under what Aleksandar described as case b).
Alexander
Am Fr, den 05.08.2005 schrieb Aleksandar Milivojevic um 17:06:
Is it possible to have a route stick in the kernel, even if device it points to goes to roller coaster up and down drive.
For example. I have an ADSL modem and am doing VPN over it. There's a route needed for VPN added like this:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
There are two problems with it:
a) if ADSL link is down when above command is executed, the route command will fail (ppp0 is down, so there's no 1.2.3.4)
b) if ADSL link is up when above command is executed, but it goes down (and up again) later, the route is removed from kernel routing tables
So, if there are any problems with ADSL link, I need to manually reset my VPN
Aleksandar Milivojevic
The network scripts are prepared for this. Create a file called /etc/sysconfig/network-scripts/route-<devicename> with content "192.168.1.0/24 via 1.2.3.4 src 192.168.2.1" (the ip route add is executed by the network script automatically). You can read about that in /usr/share/doc/initscripts*/sysconfig.txt.
Alexander
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
The network scripts are prepared for this. Create a file called /etc/sysconfig/network-scripts/route-<devicename> with content "192.168.1.0/24 via 1.2.3.4 src 192.168.2.1" (the ip route add is executed by the network script automatically). You can read about that in /usr/share/doc/initscripts*/sysconfig.txt.
ADDRESS0=192.168.1.0 NETMASK0=255.255.255.0 PREFIX=255.255.255.0 GATEWAY0=1.2.3.4
Quoting Feizhou feizhou@graffiti.net:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
The network scripts are prepared for this. Create a file called /etc/sysconfig/network-scripts/route-<devicename> with content "192.168.1.0/24 via 1.2.3.4 src 192.168.2.1" (the ip route add is executed by the network script automatically). You can read about that in /usr/share/doc/initscripts*/sysconfig.txt.
ADDRESS0=192.168.1.0 NETMASK0=255.255.255.0 PREFIX=255.255.255.0 GATEWAY0=1.2.3.4
I know how to setup static routes, but thanks anyhow ;-)
The problem is, you can't force "src" arguement for ip route command using routes-* file(s). And the only purpuse of those routes is the "src" arguement (the route itself is never used, since there's IPSec policy for that network in place, forcing packets to be tunneled). The second problem is that correct parameters for the route are calculated by ifup-ipsec script (not the one in current initscripts package, the one that will be part of CentOS 4.2). So basically, the route-* files are more or less useless here.
Anyhow, it seems that some other stuff needs to be reset for IPSEC VPN (like IPSec policies), so doing ifup of the VPNs was the only way to guarantee they get up when network connection is restored (plus current initscripts attempt to initialize IPSEC before they initialize xDSL, which doesn't quiet work).
Anyhow, the more I work with native Linux IPSec, the more it seems to me decision not to assign virtual interface (like ipsec* or tun*, like some other VPN implementations do) to tunnels was a mistake (maybe current way looks cleaner to kernel developer, but the old way was way simpler to manage for system administrator).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Fri, 2005-08-05 at 11:13, Aleksandar Milivojevic wrote:
Anyhow, the more I work with native Linux IPSec, the more it seems to me decision not to assign virtual interface (like ipsec* or tun*, like some other VPN implementations do) to tunnels was a mistake (maybe current way looks cleaner to kernel developer, but the old way was way simpler to manage for system administrator).
Can you fix this the way it is commonly done in routers? That is, configure a GRE tunnel as the end points to get a real-looking interface that you can route over, do multicast, etc., and then push the GRE packets through ipsec. I've wondered if this would work between a Linux box and a Cisco router but never had time to test it. (I have done GRE tunnels and multicast, just not the ipsec part).
Quoting Les Mikesell lesmikesell@gmail.com:
On Fri, 2005-08-05 at 11:13, Aleksandar Milivojevic wrote:
Anyhow, the more I work with native Linux IPSec, the more it seems to me decision not to assign virtual interface (like ipsec* or tun*, like some other VPN implementations do) to tunnels was a mistake (maybe current way looks cleaner to kernel developer, but the old way was way simpler to manage for system administrator).
Can you fix this the way it is commonly done in routers? That is, configure a GRE tunnel as the end points to get a real-looking interface that you can route over, do multicast, etc., and then push the GRE packets through ipsec. I've wondered if this would work between a Linux box and a Cisco router but never had time to test it. (I have done GRE tunnels and multicast, just not the ipsec part).
Well, I did some preliminary testing, and basically it seems to be working between two CentOS boxes. For testing, I've created GRE tunnel between two boxes, and then configured IPSec in transport mode between their external interfaces. Then pinged from one to another using addresses of local interfaces. Ping worked, and tcpdump showed ESP packets happily flying around.
Now, this works between two CentOS boxes (kernel 2.6.9-11.EL). If the same thing works between two Cisco routers, and GRE and IPSec on their own work between Cisco and Linux, I'd say there's good chance that GRE+IPSec will work too.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Fri, 2005-08-05 at 14:16, Aleksandar Milivojevic wrote:
Can you fix this the way it is commonly done in routers? That is, configure a GRE tunnel as the end points to get a real-looking interface that you can route over, do multicast, etc., and then push the GRE packets through ipsec. I've wondered if this would work between a Linux box and a Cisco router but never had time to test it. (I have done GRE tunnels and multicast, just not the ipsec part).
Well, I did some preliminary testing, and basically it seems to be working between two CentOS boxes. For testing, I've created GRE tunnel between two boxes, and then configured IPSec in transport mode between their external interfaces. Then pinged from one to another using addresses of local interfaces. Ping worked, and tcpdump showed ESP packets happily flying around.
Now, this works between two CentOS boxes (kernel 2.6.9-11.EL). If the same thing works between two Cisco routers, and GRE and IPSec on their own work between Cisco and Linux, I'd say there's good chance that GRE+IPSec will work too.
This should give you an interface that looks real enough to run zebra with rip or ospf and at least in theory it should work the same with a cisco at the other end.
Quoting Les Mikesell lesmikesell@gmail.com:
This should give you an interface that looks real enough to run zebra with rip or ospf and at least in theory it should work the same with a cisco at the other end.
I've just ran into one interesting problem with this approach. Seems that Netfilter is getting confused or something... Or at least I wasn't been able to make an usable config.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Fri, 2005-08-05 at 14:59, Aleksandar Milivojevic wrote:
This should give you an interface that looks real enough to run zebra with rip or ospf and at least in theory it should work the same with a cisco at the other end.
I've just ran into one interesting problem with this approach. Seems that Netfilter is getting confused or something... Or at least I wasn't been able to make an usable config.
Does ifconfig show the GRE tunnel as a PTP interface or something with a reasonable netmask? If something is trying to figure out how to access it, you might want to make it look like a 4-host subnet (netmask 255.255.255.252) using the 2 usable addresses for the endpoints.
Quoting Les Mikesell lesmikesell@gmail.com:
On Fri, 2005-08-05 at 14:59, Aleksandar Milivojevic wrote:
This should give you an interface that looks real enough to run zebra with rip or ospf and at least in theory it should work the same with a cisco at the other end.
I've just ran into one interesting problem with this approach. Seems that Netfilter is getting confused or something... Or at least I wasn't been able to make an usable config.
Does ifconfig show the GRE tunnel as a PTP interface or something with a reasonable netmask? If something is trying to figure out how to access it, you might want to make it look like a 4-host subnet (netmask 255.255.255.252) using the 2 usable addresses for the endpoints.
It showes up as PtP interface to itself (!?). Strange, but seems to work. Well, at least as long as I don't have Netfilter enabled.
Basically, I configured GRE tunnel like this:
# ip tunnel add neta mode gre remote 1.2.3.4 local 4.3.2.1 ttl 255 # ip link set neta up # ip addr add 10.0.0.2 dev neta # ip route add 10.1.2.0/24 dev neta src 10.2.1.1
Anyhow, I'm still into debugging Netfilter stuff, and came across this strange story of single ICMP echo/reply path through Netfilter's chains and tables:
mangle prerouting eth0 1.2.3.4 -> 4.3.2.1 ESP nat prerouting eth0 1.2.3.4 -> 4.3.2.1 ESP mangle input eth0 1.2.3.4 -> 4.3.2.1 ESP filter input eth0 1.2.3.4 -> 4.3.2.1 ESP mangle prerouting neta 10.1.2.1 -> 10.2.1.1 ICMP nat prerouting neta 10.1.2.1 -> 10.2.1.1 ICMP mangle input neta 10.1.2.1 -> 10.2.1.1 ICMP filter input neta 10.1.2.1 -> 10.2.1.1 ICMP
So on incomming packet, I never see GRE. A bit different story on output packet:
mangle output neta 10.2.1.1 -> 10.1.2.1 ICMP filter output neta 10.2.1.1 -> 10.1.2.1 ICMP mangle postrouting neta 10.2.1.1 -> 10.1.2.1 ICMP mangle output eth0 4.3.2.1 -> 1.2.3.4 GRE nat output eth0 4.3.2.1 -> 1.2.3.4 GRE filter output eth0 4.3.2.1 -> 1.2.3.4 GRE mangle postrouting eth0 4.3.2.1 -> 1.2.3.4 ESP nat postrouting eth0 4.3.3.1 -> 1.2.3.4 ESP
This might be the reason why I'm experiencing problems with connection tracking (various chains being skipped at some encapsulation levels). But I'm still in the middle of debugging this thing.... Will keep group posted.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Quoting Les Mikesell lesmikesell@gmail.com:
I've just ran into one interesting problem with this approach. Seems that Netfilter is getting confused or something... Or at least I wasn't been able to make an usable config.
Does ifconfig show the GRE tunnel as a PTP interface or something with a reasonable netmask? If something is trying to figure out how to access it, you might want to make it look like a 4-host subnet (netmask 255.255.255.252) using the 2 usable addresses for the endpoints.
Well, after some debugging, the problem seems to be that Netfilter is not placing returning packets into establieshed state for direct connections between VPN gateways (public addresses, those that should not go through GRE tunnel, just IPSec encrypted). If I use private interface addresses of VPN gateways (so that packets go through GRE tunnel, and then IPSec), things seem to work OK. However, I still need to do some additional testing.
Have you seen something like that before?
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Fri, 2005-08-05 at 16:09, Aleksandar Milivojevic wrote:
Well, after some debugging, the problem seems to be that Netfilter is not placing returning packets into establieshed state for direct connections between VPN gateways (public addresses, those that should not go through GRE tunnel, just IPSec encrypted). If I use private interface addresses of VPN gateways (so that packets go through GRE tunnel, and then IPSec), things seem to work OK. However, I still need to do some additional testing.
Have you seen something like that before?
One thing I've seen before is that if you have made an ip_conntrack entry for a connection before adding the route into the tunnel (e.g. a packet has already gone out the default route) the entry doesn't go away when you change the route. If there was NAT associated with the other interface, when the route changes, the nat entry stays and the packet goes over the private link but is source-natted to the other interface address and won't work. Does it make a difference if you connect to something that had not been connected before changing the route?
Les Mikesell wrote:
On Fri, 2005-08-05 at 16:09, Aleksandar Milivojevic wrote:
Well, after some debugging, the problem seems to be that Netfilter is not placing returning packets into establieshed state for direct connections between VPN gateways (public addresses, those that should not go through GRE tunnel, just IPSec encrypted). If I use private interface addresses of VPN gateways (so that packets go through GRE tunnel, and then IPSec), things seem to work OK. However, I still need to do some additional testing.
Have you seen something like that before?
One thing I've seen before is that if you have made an ip_conntrack entry for a connection before adding the route into the tunnel (e.g. a packet has already gone out the default route) the entry doesn't go away when you change the route. If there was NAT associated with the other interface, when the route changes, the nat entry stays and the packet goes over the private link but is source-natted to the other interface address and won't work. Does it make a difference if you connect to something that had not been connected before changing the route?
No, haven't tried that. However, the problematic packets are not the ones going to tunnel. I had problems with packets that are not affected by change of routing (those having external IP addresses). What I'll try on Monday is using IPSec by itself (in transport mode), and GRE by itself, and see if in any of those two cases I'll get the same problem (might send question to Netfilter list too).
Just for the complete info. I'm not using NAT. Also, while experimenting I was doing /etc/init.d/iptables restart, which would also reload connection tracking module (effectively clearing all connection tracking tables in kernel).
Quoting Aleksandar Milivojevic alex@milivojevic.org:
No, haven't tried that. However, the problematic packets are not the ones going to tunnel. I had problems with packets that are not affected by change of routing (those having external IP addresses). What I'll try on Monday is using IPSec by itself (in transport mode), and GRE by itself, and see if in any of those two cases I'll get the same problem (might send question to Netfilter list too).
Well, I think I might have found bug in Netfilter.
If I define IPSec in transport mode between two hosts, and than try to ping one host from the other, Netfilter is not placing the returning packet (ping reply) into established state. The quick and easy workaround is defining IPSec in tunneling mode and using endpoint IP addresses as SRCNET and DSTNET.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Mon, 2005-08-08 at 09:49, Aleksandar Milivojevic wrote:
Quoting Aleksandar Milivojevic alex@milivojevic.org:
No, haven't tried that. However, the problematic packets are not the ones going to tunnel. I had problems with packets that are not affected by change of routing (those having external IP addresses). What I'll try on Monday is using IPSec by itself (in transport mode), and GRE by itself, and see if in any of those two cases I'll get the same problem (might send question to Netfilter list too).
Well, I think I might have found bug in Netfilter.
If I define IPSec in transport mode between two hosts, and than try to ping one host from the other, Netfilter is not placing the returning packet (ping reply) into established state. The quick and easy workaround is defining IPSec in tunneling mode and using endpoint IP addresses as SRCNET and DSTNET.
Does 'established' make any sense for anything but tcp?
Quoting Les Mikesell lesmikesell@gmail.com:
Does 'established' make any sense for anything but tcp?
Yes, it does.
For UDP packets, it means firewall already saw a matching packet (in either direction). There's one thing to watch out, there's timeout for how long kernel keeps UDP connection tracking tables, so if "connection" (I know it's not a connection, but for a lack of better word) is idle for a bit longer time, the next packet will go to "new" state. However, for some protocols it is still usefull (for example DNS queries).
ICMP mostly goes to "related" state. The ICMP ping reply goes to established.
Anyhow, back to the original problem.
There's a bug in kernel (Netfilter). Well, there's several related to the same issue. If IPSec is in transport mode, the packets will go through Netfilter tables only once (as encrypted ESP packet). That's why ICMP ping reply was in new state. Netfilter never saw ICMP ping request (it only saw encrypted ESP packet).
The workaround is to configure IPSec in tunnel mode, but instead of using local network addresses for the policy, use external IP address of VPN gateway. This effectively gives same functionality as transport mode.
According to Netfilter developers, the bug is really hard to solve, and they were working on it for a very long time. Even in tunnel mode incomming packets are going through Netfilter tables only once, but this time same chains are propageted with encrypted packet, and some chains with decrypted packet. So it is kind of usable, unless you want to do some fancy NATing. There were some proposed patches, but they were not good enough to be included into mainstream kernel, and were finally abandoned.
Thanks for the hint to check out GRE. It works great (now that I'm aware of Netfilter's bug, and the ways to work around it). Now I have interfaces that I can route to, and even writing Netfilter firewall rules is much simpler than by using IPSec's tunneling. And I don't have to worry if my ADSL link goes down and up.
Hopefully it can also work between Linux and Cisco routers (can't test it out, none of my Cisco routers came with IPSec functionality enabled).
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
New question, but slightly related so I'll leave the subject:
If you have routes that come and go, is there some way to clear the NAT table to fix the case where a nat association is already present when a new route through a different interface is added for that destination?
I've had trouble with this in the past using a 2.4 kernel (didn't seem to happen under 2.2 and ipchains) and wondered if it is fixed in 2.6 so that nat associations go away when the route changes to go through a different interface.
Aleksandar Milivojevic wrote:
Is it possible to have a route stick in the kernel, even if device it points to goes to roller coaster up and down drive.
For example. I have an ADSL modem and am doing VPN over it. There's a route needed for VPN added like this:
ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1
There are two problems with it:
a) if ADSL link is down when above command is executed, the route command will fail (ppp0 is down, so there's no 1.2.3.4)
b) if ADSL link is up when above command is executed, but it goes down (and up again) later, the route is removed from kernel routing tables
So, if there are any problems with ADSL link, I need to manually reset my VPN setup.
I could write some monitoring script (and call it from cron) that would check if route is present and attempt to readd it if needed, but I'd rather be able to have the route either sticky (not removed when interface goes down) or automatically reenabled by the kernel when interface goes up again.
no need.
create /etc/ppp/ip-up.local and /etc/ppp/ip-down.local to handle these.
When ADSL goes up, the pppd daemon can run ip-up.local to setup the routes needed and when it goes down, the pppd daemon can run ip-down.local to fix things or remove those routes.
However, ADSL and VPN may imply move than one ppp interface (pptp based vpns) and if that is the case you want to add logic to differentiate whether you are handling the ADSL ppp interface or the VPN interface.
Quoting Feizhou feizhou@graffiti.net:
create /etc/ppp/ip-up.local and /etc/ppp/ip-down.local to handle these.
When ADSL goes up, the pppd daemon can run ip-up.local to setup the routes needed and when it goes down, the pppd daemon can run ip-down.local to fix things or remove those routes.
However, ADSL and VPN may imply move than one ppp interface (pptp based vpns) and if that is the case you want to add logic to differentiate whether you are handling the ADSL ppp interface or the VPN interface.
Thanks, using ip-up.local solved my problem. I've placed follwing script into it:
#! /bin/sh
cd /etc/sysconfig/network-scripts for ifconfig in `ls ifcfg-*`; do unset TYPE . $ifconfig if [ "$TYPE" = "IPSEC" ]; then vpn=`echo $ifconfig | cut -f2 -d'-'` ifdown $vpn ifup $vpn fi done
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
} Is it possible to have a route stick in the kernel, even if device it } points to } goes to roller coaster up and down drive. } } For example. I have an ADSL modem and am doing VPN over it. There's a } route } needed for VPN added like this: } } ip route add 192.168.1.0/24 via 1.2.3.4 src 192.168.2.1 } } There are two problems with it: } } a) if ADSL link is down when above command is executed, the route command } will } fail (ppp0 is down, so there's no 1.2.3.4) } } b) if ADSL link is up when above command is executed, but it goes down } (and up } again) later, the route is removed from kernel routing tables } } Thanks, } Aleksandar Milivojevic
off topic
may i ask what brand and model of adsl modem you are using?
i am guessing it is an internal unit and works with Linux and specifically CentOS
:)
-- Robert Hanson Abba Communications http://www.abbacomm.net
Robert Hanson wrote:
off topic
may i ask what brand and model of adsl modem you are using?
i am guessing it is an internal unit and works with Linux and specifically CentOS
It's some "never heard of it" brand, got it from ISP, the modem is back at work so I can't check the label right now. The ISP is probably giving away the cheapest ones it could find. It's external unit that can be hooked to the PC via either USB or Ethernet cable. I have it connected via Ethernet cable. I guess any external ADSL modem that connects to PC via Ethernet cable would work with Linux. Not sure about support for USB and internal versions. I think even on Windows you might need special drivers for those (while classic Ethernet connected work out of the box).
-
Aleksandar Milivojevic -
Alexander Dalloz -
Dan Gorman -
Feizhou -
Les Mikesell -
manuel bertrand -
Robert Hanson