[nycbug-talk] FreeBSD Dual homed

[Lonnie Olson]

On Dec 20, 2007, at 2:24 PM, Rodrique Heron wrote:
> # ifconfig -a
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        inet 150.210.240.36 netmask 0xffffff00 broadcast  
> 150.210.240.255
> em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        inet 150.210.160.243 netmask 0xffffff00 broadcast  
> 150.210.160.255

> # netstat -rn -f inet
> Routing tables
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif  
> Expire
> default            150.210.160.254    UGS         0      415    em1
> 150.210.160/24     link#2             UC          0        0    em1
> 150.210.240/24     link#1             UC          0        0    em0

You could have a problem with your ISP using some sort of anti IP  
spoofing measures.
An SSH connection to 150.210.240.36 would not work in that case.

The incoming packets will come in on the em0 interface as expected,  
but outgoing packets will travel out of the em1 interface.  All  
routing decisions are solely based on the destination address, and  
have nothing to do with the source address.  And you default route is  
150.210.160.254 which lies on the em1 interface.

Anti IP spoofing measures would cause a problem here.  In general your  
ISP could be filtering traffic coming from your em1 interface that  
does not have a source address of 150.210.160.0/24.   Probably the  
same as filtering traffic coming from em0 that does not have a source  
of 150.210.240.0/24.  This type of filtering can be fairly common,  
since it is rarely problematic, easy to implement, and reduces lots of  
abuse.

If this is the case, connections to 150.210.160.243 should work fine.   
Solutions to this problem are having your ISP allow both subnets on  
both interfaces, or using some other magic to make routing decisions  
based on source address.

If this isn't the case, it may take some tcpdump'ing to watch the  
traffic on the interfaces to see what is really happening.

--lonnie