RE: routing, cipe using wrong interface (long)
Markus Röder <[email protected]> Fri, 23 Jan 2004 13:36:47 +0100
| Newsgroups | gmane.comp.encryption.cipe |
|---|---|
| Message-ID | <[email protected]> |
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>