From: Tore Anderson <tore.anderson@redpill-linpro.com>
To: Jesse Molina <jesse@opendreams.net>
Cc: netfilter@vger.kernel.org
Subject: Re: How do we arp for NAT? Secondary IPs, proxy arp? something else?
Date: Sun, 24 May 2009 23:55:29 +0200 [thread overview]
Message-ID: <4A19C251.3090504@redpill-linpro.com> (raw)
In-Reply-To: <4A19B5F1.4080000@opendreams.net>
* Jesse Molina
> That's a pretty good suggestion, but it's more of a workaround than
> something that actually addresses the issue at hand. I'm looking for a
> solution on the GNU/Linux host, not in the world around it.
Why is that? Isn't making things work the most important thing to you?
Accurately setting up the routing tables (on all involved devices) isn't
a workaround, it's the most logical solution. I'm sorry that you have
an uncooperative provider - that's the problem that requires a
"workaround", in my opinion.
> To restate my question: What alternative ways are there to make the
> GNU/Linux system reply to ARP requests for an IP, without that IP being
> an actual interface on the host, or that interface must not be used by
> local services *in any way*, for the reasons of using it via SNAT/DNAT?
I'm not sure you can make Linux respond to ARP solicitations without
having a local IP address. Perhaps you use arptables to mangle the
addresses used for NAT to/from the firewall's local address (in both the
inbound and the outbound directions) - no guarantees it will work
though, I never tried it.
You can also simply add the addresses to a local interface on the
firewall, so that ARP requests will be answered. Preventing access to
local services running on the firewall through those addresses is easy,
just add rules to iptables' INPUT chain that discard any traffic
destined for them.
> Here is an example where the solution you suggested would not work: I
> have a Qwest ADSL line with a /29 network. That's what we have, and
> it's not going to change. Qwest will not issue you a /30 for the
> point-to-point between the ADSL router device and your GNU/Linux
> firewall.
If you have admin access to the Qwest router, you could still use my
initial suggestion by adding static routes to the NAT-ed addresses using
the primary address of your firewall as the next-hop. The more specific
routes will take precedence over the link-local /29, and things will
work just fine. It feels a bit more like a hack this way, though.
Another option is to add static entries in the ARP table of the ADSL
router for the addresses used for NAT, that way you don't have to
persuade the firewall to reply to ARP for non-local adresses.
BR,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
next prev parent reply other threads:[~2009-05-24 21:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-24 10:37 How do we arp for NAT? Secondary IPs, proxy arp? something else? Jesse Molina
2009-05-24 11:19 ` Tore Anderson
2009-05-24 21:02 ` Jesse Molina
2009-05-24 21:55 ` Tore Anderson [this message]
2009-05-24 23:27 ` Mike Wright
2009-05-25 9:14 ` Pascal Hambourg
2009-05-29 8:09 ` Jesse Molina
2009-06-12 7:12 ` Jesse Molina
[not found] ` <20090524164956.6f3fa24e@catlap>
2009-05-24 21:15 ` Jesse Molina
2009-05-25 4:51 ` Robert Nichols
2009-05-25 7:21 ` Покотиленко Костик
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A19C251.3090504@redpill-linpro.com \
--to=tore.anderson@redpill-linpro.com \
--cc=jesse@opendreams.net \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox