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
--
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
