# IPv4 Source Address Selection



## rmh (Jan 11, 2009)

[font="Arial"]I am setting a FreeBSD router (7.1 Release) and have run into a problem with the address it is using for outgoing traffic orginated from the FreeBSD system.  Traffic from nodes on the attached links is fine. 

The config looks like:

```
| DSL
               | 66.xxx.xxx.0
            -------
            | DSL |
            | rtr |
            -------
               | 192.168.0.1/16
               |
               | VR1 192.168.0.2/16
           ---------
           |FreeBSD| VR2  66.xxx.xxx.1/29
           |  rtr  |--------
           |  7.1  |
           ---------
      	       | VR3 10.0.0.1/8
               |
```
The 10.0.0.0/8 subnet is NATed using PF.  The 66.x.x.x/29 is public space.  The DLS router has static routes that point the 66.xxx.xxx.1/29 to 192.168.0.2.  The FreeBSD system has a default route set to 192.168.0.1.

Traffic from nodes on the VR2 and VR3 links works fine.  NAT works fine on VR3.  The problem is that traffic that originates from the FreeBSD system itself (i.e., ping from the console, NTP, etc.) uses the 192.168.0.2 address on VR1.  This doesn't work because it is private address space.  I assume it is picking this address because of the default address statement in rc.conf.

How can I tell FreeBSD to use a different address to originate traffic, such as 66.xxx.xxx.1?    Pings of the form 

`% ping -S 66.xxx.xxx.1 209.85.171.100`

work fine.

Thanks an advance.
[/font]


----------



## gordon@ (Jan 12, 2009)

I believe the way you would do this is to NAT the VR1 interface as well. Basically, any traffic that is originating as 192.168.0.2 should be NATed to your 66.xxx.xxx.1 address. It may take some experimentation to get the right options.


----------



## honk (Jan 13, 2009)

Why don't you do NAT on your DSL router? Why do you wanna have the puplic ip on your FreeBSD-box?


----------



## rmh (Jan 13, 2009)

> Why don't you do NAT on your DSL router? Why do you wanna have the
> puplic ip on your FreeBSD-box?



Two reasons.  I have a block of public addresses on one subnet that I want to make accessible to the world, and I want to be able to ssh into the FreeBSD router to mange it remotely.  If I ran NAT on the DSL box, I couldn't do either.


----------



## rmh (Jan 24, 2009)

I finally gave up on getting it to work in the way I originally planned.   I ended up bridging the VR1 and VR2 interfaces and have the block of public IP addresses on the resulting bridge interface. 

The updated config looks like:

```
| DSL
               | xxx.xxx.xxx.xxx (dynamic from ISP)
            -------
            | DSL |
            | rtr |
            -------
               | 66.xxx.xxx.1/29
               |
               | VR1 ***
           ---------    ** bridge0 66.xxx.xxx.2/29
           |FreeBSD| VR2 ***
           |  rtr  |--------
           |  7.1  |
           ---------
               | VR3 10.0.0.1/8
               |

      default 66.xxx.xxx.1
```

The good news is this does work.  I can NAT on the outgoing interface address (66.xxx.xxx.2).  The 10.0.0.0/8 interface is NATed and the remaining 66.xxx.xxx.2-6 are not.  I use PF to get finer filter control on traffic between VR1 and VR2.

I still think FreeBSD needs more control over source address selection when using public and private addresses (similar to what IPv6 has), but this does work and does what I want.

I also have IPv6 configured on VR2 and VR3 and a IPv6overIPv4 tunnel on VR1.  No need for NAT on that.

Finally I did run into what looks like a bug in the RC system when setting up the bridge.  The behavior was that even though the rc.conf lines were correct, the interfaces were not being added to the bridge interface.  I found that after booting I could enter the appropriate ifconfig commands in a shell to add the interfaces to the bridge interface, so it's not the bridge code itself.  My work around was to add the same ifconfig commands to rc.local.  That works.  This leads me to think it is some sort of timing problem in RC.

Anyone else seen this?  I will file a bug.


----------

