Re: Openbsd 3.0 stable routing problems

["Price, Joe" <JPrice@CECControls.com>]

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