Re: How to override the default source ipv4 address on packets originating from a router

[Brian Burch <brian@pingtoo.com>]

On 20/12/13 13:33, Erik Auerswald wrote:
> Hi Brian,
>
> On Fri, Dec 20, 2013 at 12:05:05PM +0000, Brian Burch wrote:
>> The mailing list has been dormant for 2 years, so I wonder whether
>> anyone is still listening for new questions?
>
> You never know. ;-)

Well, it is great to discover three people were listening and cared 
enough to help me with my puzzle. Thanks very much.

>> My broadband router runs PPPoA and is dynamically assigned a single
>> ipv4 internet address by my ISP. I have a static subnet which I host
>> on a linux router/firewall (called chenin). The linux firewall and
>> the adsl router communicate via a non-internet-addressable private
>> subnet. Here is the topology:
>>
>> Internet -- adsl-router-ppp0-ipv4-dynamic
>>           -- adsl-router-eth0-172.16.101.1
>>           --
>>           -- firewall-router-eth0-172.16.101.2
>>           -- firewall-router-217.154.193.209
>>           --
>>           -- static-subnet-hosts-217.154.193.154.208/28
>>
>> Each of the hosts on the static subnet use 217.154.193.209 as their
>> own default route. The adsl router forwards all incoming packets to
>> the firewall/router's eth0. The firewall/router forwards all
>> incoming packets to the static subnet via its own eth1. The
>> firewall/router does not need to perform NAT, but it implements a
>> simple set of iptables rules for blacklisting, etc. /All this works
>> perfectly./
>>
>> My problem is that I need to download software updates (debian
>> apt-get http) for the firewall/router from a repository out on the
>> internet.
>>
>> The firewall/router can successfully ping the repo-server when I
>> force the source address like this:
>>
>>      ping -I 217.154.193.209 163.1.221.67
>>
>> ... but a simple "ping 163.1.221.67" (i.e. using the default source
>> address selection algorithm) fails. Wireshark confirms these
>> unanswered packets go out on eth0 with a source address of
>> 172.16.101.2.
>
> I see several generic ways to solve this. Use one of:
>
> 1) Use NAT for the transfer network addresses (i.e. "masquerading" for the
>     172.16.101.2 address) on the ADSL router.

Yes, NAT would certainly work. However, I always felt it was overkill 
for what I felt looked like a routing problem. NAT is essential when a 
host ONLY has interfaces that are non-internet-addressable (aka private 
ipv4 addresses). This particular host has an interface assigned an 
internet-routeable address, so I felt the most elegant solution would be 
to somehow coerce the source address to that of the "wrong" interface in 
similar manner to the way ping's "-I" argument does.

> 2) Use SNAT from 172.16.101.2 to 217.154.193.209 on the firewall for
>     packets going to the internet.

Yes, I can see that would work too, but it is still NAT.

> 3) Use a subnet from your routable IP addresses for the transit network.

Good point. I have a couple of spare addresses that I use occasionally 
when working on the dirty side of my real firewalls. I realised I could 
permanently assign a second subnet address to the router/firewall, but 
there were three things that made me hesitate:
a) I don't have many spare addresses, and I'm stingy.
b) I couldn't sub-net my subnet without losing too many addresses. I 
don't want to redesign my internet-facing services to use fewer addresses.
c) I couldn't see a simple way to "hang" an extra address on the 
router/firewall so that it would have highest preference during source 
address selection.

> 4) Terminate PPPoE on the firewall, using the ADSL router as an ADSL modem.

Been there and got the T-shirt! My ISP is very good to me and has some 
excellent tech documents on why many UK ADSL users can't use PPPoE, even 
though it initially seems to work. I learnt the hard way that my own 
line is currently assigned to buggy exchange equipment that doesn't and 
will never work properly with PPPoE. That is why I reverted to using 
PPPoA and had to use a private subnet between the ADSL router and the 
internet-subnet router.

> You may be able to define the source IP to use for the update process. If
> so, you do not need any of the above.

Hmmm. I don't know how to do that with apt-get.

>> I believe I should be able to resolve this problem with iproute2
>> policy routing, but so far I have not been successful. I've tried
>> several variations, but they all give me the same "wrong" source
>> address.
>
> Policy routing is used _after_ deciding on the source IP address to use.

Yes... Joel also pointed out the same restriction. (I think you 
mis-typed and meant to say "policy routing happens _before_ selection of 
the source IP address").

>> Am I trying to do the impossible here, or am I just making a mistake
>> in the way I am doing it?
>
> You need to change the source IP address seen on the internet, that cannot
> be done with policy routing. It can be done using NAT, network renumbering
> or software configuration.

Joel suggested a way to turn the problem upside down and solve it with 
policy routing, so I am going to try his approach first.

> HTH,

OH YES IT DID! Thanks very much for your suggestions. I hope you are not 
offended that I am currently shelving them if/until I become more desperate.

Regards,

Brian

> Erik
>