RE: routing, cipe using wrong interface (long)
"Mark Smith" <[email protected]> Fri, 23 Jan 2004 13:07:44 -0000
| Newsgroups | gmane.comp.encryption.cipe |
|---|---|
| Message-ID | <[email protected]> |
Markus, Do you have a loopback interface? The IP address you're trying to ping from what I can see is your own end of the CIPE tunnel, which probably shouldn't generate any traffic at all. This is assuming all of the config you've given us is from your end of the tunnel... -- Mark Smith - Avco Systems Ltd email: [email protected] Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078 > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > Markus Roder > Sent: 23 January 2004 12:37 > To: Mark Smith > Cc: [email protected] > Subject: RE: routing, cipe using wrong interface (long) > > > I knew i was missing some info. > > Here's the routing table with ciped running > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref > Use Iface > 218.8.158.2 0.0.0.0 255.255.255.255 UH 0 0 > 0 ippp0 > 195.27.93.15 0.0.0.0 255.255.255.255 UH 0 0 > 0 ippp0 > 212.56.240.62 0.0.0.0 255.255.255.255 UH 0 0 > 0 ippp0 > 212.56.240.60 0.0.0.0 255.255.255.255 UH 0 0 > 0 ppp0 > 172.31.0.6 0.0.0.0 255.255.255.255 UH 0 0 > 0 cipcb0 > 195.27.93.5 0.0.0.0 255.255.255.255 UH 0 0 > 0 ippp0 > 218.8.157.152 0.0.0.0 255.255.255.248 U 0 0 > 0 eth1 > 172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 > 0 dvb0_0 > 93.0.0.0 0.0.0.0 255.0.0.0 U 0 0 > 0 eth0 > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 > 0 ppp0 > DialUp is connected in this case > > > > At 12:19 23.01.2004 +0000, you wrote: > >Markus, > > > >You don't include the contents of your routing table after the > CIPE tunnel > >is established, since more entries will have been added. > > > >If you could post a copy, it might help explain the traffic at > that point. > > > >Take care, > > > >-- > >Mark Smith - Avco Systems Ltd > >email: [email protected] > >Tel: +44 (0)1784 430996 Fax: +44 (0)1784 431078 > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On Behalf Of > > > Markus Roder > > > Sent: 23 January 2004 11:37 > > > To: [email protected] > > > Subject: routing, cipe using wrong interface (long) > > > > > > > > > Hi List > > > > > > I have a very weird problem getting cipe to work. > > > I know this is quite a lot of info to read, but i hope > somebody takes the > > > time and can give me the final hint to resolve this strange behaviour > > > I have the following Setup: > > > > > > eth0: 93.0.0.2/8 #internal Net > > > eth1: 218.8.157.154/29 # official Ip's > > > ippp0: 10.0.0.10 ptp 10.0.0.11 # ISDN Dial-Up > > > dvb0_0: 172.21.16.12/16 # Dummy-Interface > > > for DSL via Sat > > > > > > Here's the routing table while ippp0 is not connected: > > > > > > Kernel IP routing table > > > Destination Gateway Genmask Flags > > > Metric Ref Use Iface > > > 10.0.0.11 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 ippp0 > > > 218.8.157.152 0.0.0.0 255.255.255.248 U 0 > > > 0 0 eth1 > > > 172.21.0.0 0.0.0.0 255.255.0.0 U 0 > > > 0 0 dvb0_0 > > > 93.0.0.0 0.0.0.0 255.0.0.0 U 0 > > > 0 0 eth0 > > > 0.0.0.0 10.0.0.11 0.0.0.0 UG 0 > > > 0 0 ippp0 > > > > > > When the Dial-Up connection is triggered I start a pptp > connection to the > > > Astra-Server generating a new device ppp0 > > > which uses the dvb0_0 interface to increase downstream > bandwidth. Routing > > > Table looks like this: > > > > > > Kernel IP routing table > > > Destination Gateway Genmask Flags > > > Metric Ref Use Iface > > > 218.8.158.2 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 > > > ippp0 # Don't use Sat for DNS > > > 195.27.93.5 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 > > > ippp0 # Secondary DNS > > > 195.27.93.15 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 > > > ippp0 # ippp0 Link-Partner > > > 212.56.240.62 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 > > > ippp0 # Astra-Server > > > 212.56.240.60 0.0.0.0 255.255.255.255 UH 0 > > > 0 0 > > > ppp0 # Astra-Server > > > 218.8.157.152 0.0.0.0 255.255.255.248 U 0 > > > 0 0 eth1 > > > 172.21.0.0 0.0.0.0 255.255.0.0 U 0 > > > 0 0 dvb0_0 > > > 93.0.0.0 0.0.0.0 255.0.0.0 U 0 > > > 0 0 eth0 > > > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 > > > 0 0 > > > ppp0 # Default using Sattelite downstream > > > > > > So far the Network Setup which is a little complicated but is working. > > > > > > Now I start cipe with the following options: > > > > > > # cat /etc/cipe/options > > > device cipcb0 > > > me 218.8.157.154:9001 > > > peer 0.0.0.0:9001 > > > ipaddr 172.31.0.5 > > > ptpaddr 172.31.0.6 > > > dynip no > > > maxerr -1 > > > key somekey > > > > > > which gives me > > > > > > # netstat -lupn > > > ... > > > udp 0 0 > > > 0.0.0.0:9001 0.0.0.0:* ESTABLISHED > 4012/ciped-cb > > > ... > > > > > > and the following in the logs: > > > Jan 23 12:21:34 tdslproxy ciped-cb[18492]: CIPE daemon vers > > > 1.5.4 (c) Olaf > > > Titz 1996-2000 > > > Jan 23 12:21:34 tdslproxy kernel: cipcb0: setpar > > > Jan 23 12:21:34 tdslproxy kernel: cipcb0: setpar 0.0.0.0:0 > > > 1000 60000 0600 0 > > > Jan 23 12:21:34 tdslproxy kernel: cipcb0: setkey > > > Jan 23 12:21:34 tdslproxy kernel: cipcb0: attach > > > Jan 23 12:21:34 tdslproxy kernel: cipcb0: opened > > > Jan 23 12:21:34 tdslproxy ciped-cb[18492]: peer > configuration info: > > > proto=3, crypto=b, version=1.5, correct key parser > > > Jan 23 12:21:34 tdslproxy ciped-cb[18492]: peer > configuration info: > > > proto=3, crypto=b, version=1.5, correct key parser > > > > > > Shouldn't cipe bind it's socket to just 218.8.157.154:9001? > > > > > > To be sure that the cipe-traffic uses the right interface i have > > > > > > # ip rule show show > > > 0: from all lookup local > > > 32765: from all fwmark 1 lookup cipe > > > 32766: from all lookup main > > > 32767: from all lookup default > > > > > > # ip route show table cipe > > > default via 218.8.157.153 dev eth1 > > > > > > iptables -t mangle -A OUTPUT -p udp --dport 9001 -j MARK > > > --set-mark 1 > > > > > > After starting the client side i get the following in > /var/log/messages: > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: new peer > > > 218.8.158.194:9001 > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_sendmsg > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_sendmsg > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: setkey > > > Jan 23 11:40:21 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_sendmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_sendmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: setkey > > > Jan 23 11:40:22 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 11:40:40 tdslproxy kernel: UDP: bad checksum. From > > > 172.31.0.6:137 > > > to 172.31.0.5:137 ulen 58 > > > Jan 23 11:40:42 tdslproxy last message repeated 2 times > > > > > > so I think the client is connected and they exchange messages > just fine. > > > tcpdump shows the traffic on interface eth1 (both directions). > > > > > > > > > Now comes the weird thing: > > > If i do a 'ping 172.31.0.5' on the connected client i can see > > > arriving cipe > > > packets on eth1, but there's no reply to those packets on eth1 > > > Upon further investigation i found that the replies take the Systems > > > default route which triggers the dial-up Link and in the Logs i get: > > > Jan 23 12:24:06 tdslproxy kernel: cipcb0: cipe_sendmsg > > > Jan 23 12:24:06 tdslproxy kernel: cipcb0: setkey > > > Jan 23 12:24:06 tdslproxy kernel: cipcb0: cipe_recvmsg > > > Jan 23 12:24:11 tdslproxy kernel: cipcb0: changing my > > > address: 172.24.130.146 > > > > > > So here comes the big question: > > > - How do i tell cipe to use the correct interface for it's traffic > > > - How do i tell cipe to bind it's listening socket to the correct > > > interface > > > ( not 0.0.0.0:9001 ) > > > > > > > > > -- > > > Message sent by the [email protected] mailing list. > > > Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body > > > Other commands available with "help" in body to the same address. > > > CIPE info and list archive: > > > <URL:http://sites.inka.de/~bigred/devel/cipe.html> > > > > > >-- > >Message sent by the [email protected] mailing list. > >Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body > >Other commands available with "help" in body to the same address. > >CIPE info and list archive: > <URL:http://sites.inka.de/~bigred/devel/cipe.html> > > > -- > Message sent by the [email protected] mailing list. > Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body > Other commands available with "help" in body to the same address. > CIPE info and list archive: > <URL:http://sites.inka.de/~bigred/devel/cipe.html> -- Message sent by the [email protected] mailing list. Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body Other commands available with "help" in body to the same address. CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>