Hi Brian,
On 12/20/2013 08:20 PM, Brian Burch wrote:
On 20/12/13 13:33, Erik Auerswald wrote:
On Fri, Dec 20, 2013 at 12:05:05PM +0000, Brian Burch wrote:
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.
Indeed, and IMHO that is the best solution. It is implemented on the
machine that needs to choose the correct IP address.
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.
No surprise. ;-)
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.
My fault, I did not read carefully and did not notice the A(TM)...
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 did a quick check and did not see a configuration option for this. :-(
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").
Well, the interface to use and thus the source IP address is decided by
a route table lookup. But a source specific route can be found only
_after_ the IP has been chosen.
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.
Please report to the list if this works (and how exactly).
You want the IP packet to egress the interface to the ADSL router, but
use the IP address of the internal interface as source address. Linux
determines the source address by using the egress interface's address.
[If a source address is specified by the application, that is used
instead (the 'ping -I' case).]
To replace a source address I'd use SNAT. I don't know the exact command
off the top of my head, though.
I am really curious if the problem can be solved with policy routing as
well. :-)
Regards,
Erik
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
