uhhm, urd -> 192.168.200.32 ! 196.168.200.32
look at your message carefully :)
> -----Original Message-----
> From: Bjorn Christianson [mailto:bjorn@mailhost.etho.caltech.edu]
> Sent: Friday, February 01, 2002 3:56 PM
> To: misc@openbsd.org
> Subject: Openbsd 3.0 stable routing problems
>
>
> Hi all,
>
> I recently upgraded from 2.9-stable to 3.0-stable, and have
> run into a problem. I've been running NAT on the OpenBSD
> box between an internal network (196.168.200/24) and the
> outside world. As of the upgrade, however, the routing has
> gone strange.
>
> If I traceroute a box on the internal network using a name
> defined in /etc/hosts, everything works:
>
> skuld:~$ traceroute urd
> traceroute to urd.homeworld.net (192.168.200.32), 64 hops
> max, 40 byte packets
> 1 urd.homeworld.net (192.168.200.32) 0.560 ms 0.536 ms 0.529 ms
>
> However, if I use the IP address itself:
> skuld:~$ traceroute 196.168.200.32
> traceroute to 196.168.200.32 (196.168.200.32), 64 hops max,
> 40 byte packets
> 1 Booth-RSM-184.caltech.edu (131.215.184.253) 174.559 ms
> 21.635 ms 54.419 ms
> 2 Booth-border.ilan.caltech.edu (131.215.254.254) 20.35
> ms 126.529 ms 14.776 ms
> 3 nabisco.dmz.caltech.edu (192.12.19.3) 29.693 ms 23.689
> ms 52.625 ms
> 4 nabisco.dmz.caltech.edu (192.12.19.3) 24.477 ms !H
>
> And so on. For some reason, the request has been routed out
> the external interface. This will happen even trying to go
> to the OpenBSD box itself:
>
> skuld:~$ traceroute 196.168.200.254
> traceroute to 196.168.200.254 (196.168.200.254), 64 hops
> max, 40 byte packets
> 1 Booth-RSM-184.caltech.edu (131.215.184.253) 25.641 ms
> 142.153 ms 18.920 ms
> 2 Booth-border.ilan.caltech.edu (131.215.254.254) 22.652
> ms 24.152 ms 24.132 ms
> 3 nabisco.dmz.caltech.edu (192.12.19.3) 137.619 ms
> 22.400 ms 16.330 ms
>
> To my admittedly unexpert eyes, the routing tables seem
> sane:
>
> skuld:~$ netstat -rn
> Routing tables
>
> Internet:
> Destination Gateway Flags Refs Use
> Mtu Interface
> default 131.215.184.254 UGS 4 4337
> 1500 dc0
> 127/8 127.0.0.1 UGRS 0 0
> 33224 lo0
> 127.0.0.1 127.0.0.1 UH 4 26
> 33224 lo0
> 131.215.184/24 link#1 UC 0 0
> 1500 dc0
> 131.215.184.254 0:0:c:7:ac:3 UHL 1 0
> 1500 dc0
> 192.168.200/24 link#2 UC 0 0
> 1500 dc1
> 192.168.200.32 0:50:da:6c:c9:92 UHL 0 9
> 1500 dc1
> 192.168.200.254 127.0.0.1 UGHS 0 0
> 33224 lo0
> 192.168.200.255 link#2 UHL 3 57
> 1500 dc1
> 224/4 127.0.0.1 URS 0 0
> 33224 lo0
>
> [snipped the IPv6]
>
> dc0 is the external interface, and dc1 is the internal
> interface. Both are Linksys LNE100TX cards:
>
> dc0 at pci0 dev 11 function 0 "ADMtek AN983" rev 0x11: irq 5
> address 00:03:6d:13:1e:e7
> ukphy0 at dc0 phy 1: Generic IEEE 802.3u media interface
> ukphy0: OUI 0x000895, model 0x0001, rev. 0
> dc1 at pci0 dev 17 function 0 "ADMtek AN983" rev 0x11: irq 9
> address 00:03:6d:13:1e:55
> ukphy1 at dc1 phy 1: Generic IEEE 802.3u media interface
> ukphy1: OUI 0x000895, model 0x0001, rev. 0
>
> This is 3.0-stable, with a GENERIC kernel. It is *not* a
> result of NAT or IP forwarding; the above traceroutes were
> obtained with both pf and net.inet.ip.fowarding disabled.
>
> I'm sure that the problem is that I'm missing something
> obvious, but I'm really at a loss. Any suggestions would be
> appreciated.
>
> Thanks in advance,
>
> Bjorn Christianson
>
> --
> bjorn@etho.caltech.edu http://www.its.caltech.edu/~bjorn
> Computation & Neural Systems, Caltech 216-76, Pasadena CA 91125
|