top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Only allow packets match interface ip using IPTables

+1 vote
455 views

I have multiple wan port and multiple routing table in a box. The wan port should be the final destination of outside word. (eg: all the packets come from internet should have destination IPAddress of my wan port, there are no further routing beyond the wan IPAddress).

rp_filter seems not work correctly under multiple routing table situation, so I need to set rp_filter to 0.

I want to know if there are simple setup method to secure the wan port ? or I need to use iptables to drop the incoming packet not matching the wan interface IP?

The problem is I have dynamic PPP interface, so matching the ip via iptables is a little complicated. so I want to know if there are smarter ways to do the job.

posted Aug 22, 2013 by Mandeep Sehgal

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

1) You are talking about two different things. rp_filter checks the source address in incoming packets, not the destination address. Besides, receiving on an interface packets which are destined to the address of another interface is rather unlikely.

2) You can use scripts in /etc/ppp/ip-{up|down}.d to add|remove iptables rules based on the local address and interface name passed by pppd when a PPP link is established|terminated.
Simple example :

#!/bin/sh
# /etc/ppp/ip-up.d/addrules

# Environment variables :
# Variable Name Example
# PPP_IFACE Interface name ppp0
# PPP_TTY The tty ttyS1
# PPP_SPEED The link speed 38400
# PPP_LOCAL Local IP number 12.34.56.78
# PPP_REMOTE Peer IP number 12.34.56.99
# PPP_IPPARAM Optional "ipparam" value foo

iptables -I INPUT -i $PPP_IFACE ! -d $PPP_LOCAL -j DROP

#!/bin/sh
# /etc/ppp/ip-up.d/delrules

# Environment variables :
# Variable Name Example
# PPP_IFACE Interface name ppp0
# PPP_TTY The tty ttyS1
# PPP_SPEED The link speed 38400
# PPP_LOCAL Local IP number 12.34.56.78
# PPP_REMOTE Peer IP number 12.34.56.99
# PPP_IPPARAM Optional "ipparam" value foo

iptables -D INPUT -i $PPP_IFACE ! -d $PPP_LOCAL -j DROP
answer Aug 24, 2013 by Sumit Pokharna
Similar Questions
+1 vote

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

+2 votes

Does the rule 'iptables -I INPUT -m state --state INVALID -j DROP' get rid of those scans? Also, what exactly does INVALID match?

+3 votes

consider this scenario:

PC1 wants to telnet to SRV1 tcp 40000.

I would like to put a proxy in the middle that receives the connection, rewrites the destination, sends packet to a local socks proxy (redsocks).

So the scenario would be:

PC1 --> PROXY tcp 20000 [iptables rewrites destination to SRV tcp 40000 --> redsocks 127.0.0.1 tcp 12345] --> SRV1 tcp 40000

I tried:
iptables -t nat -A PREROUTING -p tcp -s $MYSOURCEIP --dport 20000 -j DNAT --to $SRV1:40000

It works, but I know it doesn't go through redsocks. I just changed the destination for the packets but how can I force them to flow into redsocks?

+1 vote

I have a gateway application which I am using iptables to NAT from a LAN interface to a WAN interface (linux 3.2.6). This mostly works well, except that I sometimes see (via wireshark) IP packets being sent out
the WAN interface that originated from the LAN interface that iptables fails to apply NAT.

These packets seem to usually be FIN, FIN/ACK, or RST packets. I suspect that these are for IP connections from the device connected to the LAN interface that were setup prior to being connected to the
gateway on which I am running iptables. After some time, I think the application on the connected device decides to close these connections (FIN), but iptables fails to NAT these packets. Why?

From the iptables man page:

nat:
This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before rout-ing), and POSTROUTING (for altering packets as they are about to go out).

I'm concerned about the statement that says, "when a packet that creates a new connection is encountered". Since the SYN packet for the problem FIN,RST packets was not seen by iptables, does this mean that iptables will not NAT the FIN packet? This would seem wrong to me.

+1 vote

Recent versions of the Linux kernel and the libnftnl library define nft expression types with the names "match" and "target". However, I could not find any reference to these expression types in the code of the nft user space utility, but only in the code for iptables.

Is it possible to access iptables matches and targets from rules defined with nft, or is this not intended?

...