matching -d to a given interface without specifying ip address

matching -d to a given interface without specifying ip address

[Dmitri]

Hello,

Is there a way to define a condition "those packets whose destination is 
the IP address of the given interface" without specifying the actual IP 
address? (it changes, thus needs to be detected and updated)

I want to be able to distinguish those packets addressed to the box, to 
be forwarded, from those just passing through it. (-i matches both)

Such packets can be discovered in the INPUT chains, after the "routing 
decision", but by then it's too late to do DNAT.

Thanks,

--Dmitri

RE: matching -d to a given interface without specifying ip address

[Rob Sterenborg]

> Hello,
> 
> Is there a way to define a condition "those packets whose destination
> is the IP address of the given interface" without specifying the
> actual IP address? (it changes, thus needs to be detected and updated)

No. -d expects an IP address.

> I want to be able to distinguish those packets addressed to
> the box, to be forwarded, from those just passing through it. (-i
> matches both)

Netfilter either does DNAT or not.

Let's take http traffic as an example.
A packet arrives at the external NIC on port 80/tcp of the firewall. If
there is a DNAT rule that matches, the packets gets a new destination IP
and enters the FORWARD chain. If there's no rule that matches, it enters
the INPUT chain.

So you cannot, for example, distinguish http traffic arriving on port
80/tcp for the local box from http traffic also arriving on port 80/tcp
for your DMZ/LAN (if the firewall has only 1 external IP address).
To distinguish that traffic, you'd need to look at the http hostheader
to decide if you should forward it to the local webserver or the
webserver in your LAN/DMZ. Netfilter cannot do that.

What is it exactly what you want to accomplish?

> Such packets can be discovered in the INPUT chains, after the "routing
> decision", but by then it's too late to do DNAT.

I don't understand how you would be able to discover such packets in the
INPUT chain, because when they're there then those packets are already
accepted for your local box. But I could be wrong.



Gr,
Rob

Re: matching -d to a given interface without specifying ip address

[Dmitri]

Rob Sterenborg wrote:
>> Is there a way to define a condition "those packets whose destination
>> is the IP address of the given interface" without specifying the
>> actual IP address? (it changes, thus needs to be detected and updated)
> 
> No. -d expects an IP address.
I was looking for a (non-existent) option like 
--dest-ip-address-matches-that-of eth1. Meaning the connection is 
addressed to the box, as opposed to passing through it to some other 
machine but to the same port.

The problem with specifying an IP is that it may change, which breaks 
the rules and requires an update (and detection as well). Event for a 
static IP, that's an extra dependency to watch out for.

> What is it exactly what you want to accomplish?

Maybe this is contrived and not a good method..

I want the above-described kind of option, to pick out and DNAT 
connections on a certain port (say, http) directed at the box, but not 
those on the same port but directed elsewhere (like google being 
accessed through the box being the gateway). Purpose - to 
DNAT-encapsulate some service by the box.

(It doesn't matter from which direction it came, on which interface, its 
contents, etc. - only the destination ip.)

If i say "-d <ip.of.the.box> --dport 80 -j DNAT ..", that works, but it 
introduces the unwanted dependency on the actual IP value.

If i say "-i <interface> --dport 80..." for an internal interface, that 
catches anything, whether it was meant for the box or google.

Thanks,
--Dmitri

RE: matching -d to a given interface without specifying ip address

[Rob Sterenborg]

>> What is it exactly what you want to accomplish?
> 
> Maybe this is contrived and not a good method..
> 
> I want the above-described kind of option, to pick out and DNAT
> connections on a certain port (say, http) directed at the
> box, but not
> those on the same port but directed elsewhere (like google being
> accessed through the box being the gateway). Purpose - to
> DNAT-encapsulate some service by the box.

Yes, but there is a difference:
Here you are talking about packets that come from your client that are
sent to Google. These do not have the destination IP of the firewall box
but pass through the firewall because you have set your gateway
according. Besides, that would be SNAT which is something else.

> (It doesn't matter from which direction it came, on which
> interface, its contents, etc. - only the destination ip.)

If you have a server in your LAN (I actually don't know what your setup
is) you want to forward to and perform NAT, you are probably using a
private IP (192.168... etc) for that box. A client from the internet can
only point to your public IP and there are, in this case, only 2
dependencies that matter: destination IP and destination port. Since you
have only 1 public IP, you can specify only 1 destination port, eg 80.
Using these 2 you can either decide it's for the local server on the
firewall or for the internal server in your LAN.

> If i say "-d <ip.of.the.box> --dport 80 -j DNAT ..", that
> works, but it introduces the unwanted dependency on the actual
> IP value.
> 
> If i say "-i <interface> --dport 80..." for an internal
> interface, that catches anything, whether it was meant for
> the box or google.

Perhaps you're confusing DNAT with SNAT?
When packets for Google pass through it's (initial) direction is from
your LAN to the internet and packets are SNAT-ed. This is the opposite
of what you want above.


Gr,
Rob

Re: matching -d to a given interface without specifying ip address

[Danny Rathjens]

Dmitri wrote:
> The problem with specifying an IP is that it may change, which breaks 
> the rules and requires an update (and detection as well). Event for a 
> static IP, that's an extra dependency to watch out for.
 
That's what variables in your firewall script are for.
Just re-run it when your network connection restarts:
EXTIF="eth0"
EXTIP=`ifconfig $EXTIF |perl -ne'print $1 if /inet addr:([\d.]+)/'`
iptables -A INPUT -j ACCEPT -i $EXTIF -p tcp -d $EXTIP --dport 80
-- 
     _.,-*~`^'~*-,._ Danny Rathjens _.,-*~`^'~*-,._
FireCast: Rock solid kiosk software: http://www.wirespring.com/

Re: matching -d to a given interface without specifying ip address

[Dmitri]

Danny Rathjens wrote:
> Dmitri wrote:
>> The problem with specifying an IP is that it may change, which breaks 
>> the rules and requires an update (and detection as well). Event for a 
>> static IP, that's an extra dependency to watch out for.
> 
> That's what variables in your firewall script are for.
> Just re-run it when your network connection restarts:
> EXTIF="eth0"
> EXTIP=`ifconfig $EXTIF |perl -ne'print $1 if /inet addr:([\d.]+)/'`
> iptables -A INPUT -j ACCEPT -i $EXTIF -p tcp -d $EXTIP --dport 80

Yes, but it's exactly the sort of hack I hoped to avoid. For a perfectly 
simple expression, now I need to 1) detect that IP changed or connection 
restarted, and 2) run the hack. There isn't supposed to be any firewall 
script.

It's like SNAT vs. MASQUERADE - MASQUERADE works without any scripts or 
reloads. Same can be done with other things which require reloading. The 
less dynamic hacks in the system, the less of a nondeterministic mess it 
would be.

Well, I guess the answer to my question is "no, there is no such 
option". I'm half-considering implementing it myself, if I can find 
heads and tails of it.

Thanks,
--Dmitri

Re: matching -d to a given interface without specifying ip address

[Dmitri]

Rob Sterenborg wrote:
> Yes, but there is a difference:
> Here you are talking about packets that come from your client that are
> sent to Google. These do not have the destination IP of the firewall box
> but pass through the firewall because you have set your gateway
> according. Besides, that would be SNAT which is something else.
...
 > ... A client from the internet can
 > only point to your public IP ...

Yes, but a client from the local network can either point at google's 
ip, or the public or private IP of the gateway. I wanted to detect these 
cases. It's specifically about local clients, whichever IP they're 
pointing to.

> Perhaps you're confusing DNAT with SNAT?
> When packets for Google pass through it's (initial) direction is from
> your LAN to the internet and packets are SNAT-ed. This is the opposite
> of what you want above.

No, I'm not confusing DNAT with SNAT. SNAT, particularly MASQUERADE, is 
happening anyway for -o ppp0. But I wanted to DNAT some things directed 
to the box itself to some other destination. When they come -o ppp0, 
they will get MASQUERADEd as well.

Anyway, I think I have the answer to my question, as explained in my 
response to Danny.

Thanks,
--Dmitri

Re: matching -d to a given interface without specifying ip address

[Pascal Hambourg]

Hello,

Dmitri a écrit :
> 
> Is there a way to define a condition "those packets whose destination is 
> the IP address of the given interface" without specifying the actual IP 
> address? (it changes, thus needs to be detected and updated)

None that I'm aware of.

> I want to be able to distinguish those packets addressed to the box, to 
> be forwarded, from those just passing through it. (-i matches both)
> 
> Such packets can be discovered in the INPUT chains, after the "routing 
> decision", but by then it's too late to do DNAT.

Beware. "Packets addressed to the box (entering the given interface)" is 
not the same as "packets whose destination is the IP address of the 
given interface". The former means "packets whose destination is the IP 
address of ANY local interface". So packets matching a rule such as :

iptables -A INPUT -i <interface> ...

would match not only the former definition but also the latter, and also 
broadcasts that the box listens to.

So what do you want to match exactly ?

Re: matching -d to a given interface without specifying ip address

[Pascal Hambourg]

Dmitri a écrit :
> Danny Rathjens wrote:
> 
>> Dmitri wrote:
>>
>>> The problem with specifying an IP is that it may change, which breaks 
>>> the rules and requires an update (and detection as well). Event for a 
>>> static IP, that's an extra dependency to watch out for.
>>
>> That's what variables in your firewall script are for.
>> Just re-run it when your network connection restarts:
>> EXTIF="eth0"
>> EXTIP=`ifconfig $EXTIF |perl -ne'print $1 if /inet addr:([\d.]+)/'`
>> iptables -A INPUT -j ACCEPT -i $EXTIF -p tcp -d $EXTIP --dport 80
> 
> Yes, but it's exactly the sort of hack I hoped to avoid. For a perfectly 
> simple expression, now I need to 1) detect that IP changed or connection 
> restarted, and 2) run the hack. There isn't supposed to be any firewall 
> script.

 From what you wrote in your messages, I understand that your box serves 
as a gateway with an ethernet interface on the LAN side and a PPP 
interface on the WAN side. On the LAN side, a gateway address is not 
likely to change, so I don't see a reason to worry about changes of the 
address of the ethernet interface. On the WAN side, pppd can run scripts 
every time the PPP connection goes up or down and provide them useful 
information in environment variable such as the IP address, the peer 
address, the interface name... without the need fo hugly hacks.

> It's like SNAT vs. MASQUERADE - MASQUERADE works without any scripts or 
> reloads.

Or not. MASQUERADE does not work in some special cases when advanced 
routing is used. MASQUERADE is not just SNAT with a dynamic address, it 
is much more. For example you don't actually tell MASQUERADE "use that 
interface address" but rather "use the suitable source address for the 
packet destination".