Help with firewall/masquerading problem

Hello! I am looking for help fixing the following problem
on my home network.

My mini-network consists of a Linux firewall (Debian,
2.4.22 kernel, masquerading with iptables) and the main
workstation (Linux/Windows). The firewall has 2 NICs:
one (eth0, 10.11.1.119) connected to the ISP's network through
a cable modem; another NIC (eth1, 192.168.0.1) is connected to
the workstation. The workstation has one NIC (192.168.0.2).

The firewall seems to be working, i.e. one cannot connect
to 192.168.0.2 or ping it from the outside. However, one CAN see
and ping 192.168.0.1 from the ISP's 10.11.X.X network. This,
understandably, makes the ISP unhappy (they did check that they
are pinging my box and not someone else's 192.168.0.1 by looking
at MAC addresses).

Can anyone suggest how I can stop 192.168.0.1 from being seen on
the outside (10.11.X.X) network or point me to the relevant
manpages/documentation/FAQ?

Any help is greatly appreciated!
-- Alex


This is the firewall script that runs on startup on the firewall:

##################################################
[skip: load modules...]
IPTABLES=/sbin/iptables
EXTIF="eth0"
INTIF="eth1"
echo "External interface $EXTIF, internal interface $INTIF"

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

echo "Clearing existing rules and setting default policy"
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F

echo "Allow all connections out and only existing and related in"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG

echo "Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE


###### This is the output of /sbin/route on the firewall ######
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
10.11.0.0 * 255.255.0.0 U 0 0 0 eth0
default 10.11.1.5 0.0.0.0 UG 0 0 0 eth0

On Fri, 28 May 2004 23:32:36 -0400, Alex Meov wrote:

> Hello! I am looking for help fixing the following problem on my home
> network.
>
> My mini-network consists of a Linux firewall (Debian, 2.4.22 kernel,
> masquerading with iptables) and the main workstation (Linux/Windows). The
> firewall has 2 NICs: one (eth0, 10.11.1.119) connected to the ISP's
> network through a cable modem; another NIC (eth1, 192.168.0.1) is
> connected to the workstation. The workstation has one NIC (192.168.0.2).
>
> The firewall seems to be working, i.e. one cannot connect to 192.168.0.2
> or ping it from the outside. However, one CAN see and ping 192.168.0.1
> from the ISP's 10.11.X.X network. This, understandably, makes the ISP
> unhappy (they did check that they are pinging my box and not someone
> else's 192.168.0.1 by looking at MAC addresses).
>

>
> This is the firewall script that runs on startup on the firewall:
>
> ################################################## [skip: load modules...]
> IPTABLES=/sbin/iptables
> EXTIF="eth0"
> INTIF="eth1"
> echo "External interface $EXTIF, internal interface $INTIF"
>
> echo "1" > /proc/sys/net/ipv4/ip_forward echo "1" >
> /proc/sys/net/ipv4/ip_dynaddr
>
> echo "Clearing existing rules and setting default policy" $IPTABLES -P
> INPUT ACCEPT
> $IPTABLES -F INPUT
> $IPTABLES -P OUTPUT ACCEPT
> $IPTABLES -F OUTPUT
> $IPTABLES -P FORWARD DROP
> $IPTABLES -F FORWARD
> $IPTABLES -t nat -F
>
> echo "Allow all connections out and only existing and related in"
> $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state
> ESTABLISHED,RELATED -j ACCEPT $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j
> ACCEPT $IPTABLES -A FORWARD -j LOG

Change the input policy to "DROP" and add four more rules:

# Allow local traffic (!)
#
$IPTABLES -A INPUT -i lo -j ACCEPT
#
# Allow LAN traffic
#
$IPTABLES -A INPUT -i $INTIF -j ACCEPT
#
# Allow responses from Internet
#
$IPTABLES -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED -j
ACCEPT
#
$IPTABLES -A INPUT -j LOG

Regards, Ian

> On Fri, 28 May 2004 23:32:36 -0400, Alex Meov wrote:
>> My mini-network consists of a Linux firewall (Debian, 2.4.22 kernel,
>> masquerading with iptables) and the main workstation (Linux/Windows). The
>> firewall has 2 NICs: one (eth0, 10.11.1.119) connected to the ISP's
>> network through a cable modem; another NIC (eth1, 192.168.0.1) is
>> connected to the workstation. The workstation has one NIC (192.168.0.2).
>>
>> The firewall seems to be working, i.e. one cannot connect to 192.168.0.2
>> or ping it from the outside. However, one CAN see and ping 192.168.0.1
>> from the ISP's 10.11.X.X network.
>>
>> Can anyone suggest how I can stop 192.168.0.1 from being seen on
>> the outside (10.11.X.X) network?
On Sat, 29 May 2004 11:51:57 +0100, Ian Northeast suggested
modification of the firewall script (below).

Ian, thank you for the help! However I have received the
following information indicating that my 192.168.0.1 is
still visible from the ISP.

From the ISP:
You are still showing up in the ARP table. Here is info from a router.
Someting is still actively leaking out.
Kimball_Court_R1#sh arp | include 192
Internet 192.168.0.1 0 0005.5dd0.6a27 ARPA Cable3/0

The firewall script now is
#########################
IPTABLES=/sbin/iptables
EXTIF="eth0"
INTIF="eth1"

$IPTABLES -P INPUT DROP
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F

echo "Allow all connections out and only existing and related in"
$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m \
state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG

# Allow local traffic (!)
$IPTABLES -A INPUT -i lo -j ACCEPT
#
# Allow LAN traffic
$IPTABLES -A INPUT -i $INTIF -j ACCEPT
#
# Allow responses from Internet
$IPTABLES -A INPUT -i $EXTIF -m state --state ESTABLISHED,RELATED \
-j ACCEPT

$IPTABLES -A INPUT -j LOG

echo "Enabling SNAT (MASQUERADE) functionality on $EXTIF"
$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
#########################

Any further help is appreciated!

Best regards,
Alex

Alex Meov <(E-Mail Removed)> wrote:
> Hello! I am looking for help fixing the following problem
> on my home network.

> My mini-network consists of a Linux firewall (Debian,
> 2.4.22 kernel, masquerading with iptables) and the main
> workstation (Linux/Windows). The firewall has 2 NICs:
> one (eth0, 10.11.1.119) connected to the ISP's network through
> a cable modem; another NIC (eth1, 192.168.0.1) is connected to
> the workstation. The workstation has one NIC (192.168.0.2).

> The firewall seems to be working, i.e. one cannot connect
> to 192.168.0.2 or ping it from the outside. However, one CAN see
> and ping 192.168.0.1 from the ISP's 10.11.X.X network. This,
> understandably, makes the ISP unhappy (they did check that they
> are pinging my box and not someone else's 192.168.0.1 by looking
> at MAC addresses).

> Can anyone suggest how I can stop 192.168.0.1 from being seen on
> the outside (10.11.X.X) network or point me to the relevant
> manpages/documentation/FAQ?

You can try this:

/sbin/ifconfig eth0 -arp

I think the only way that a ping echo-request, sent from an ISP host
on 10.11.0.0/16 (?), can elicit an echo-reply from 192.168.0.1 is for
your Internet connection host to respond with the MAC address of eth1
in an ARP reply to an ARP who-has 192.168.0.1 request by the ISP host.

No guarantee, I'm not really certain this will work but certainly would
like to know whether or not it does.

BTW, thanks for the insight into how an ISP might check for clients that
use MASQUERADING/SNAT.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Speak softly and carry a sucker rod (See man syslogd, footnote to
recommendation 4 under SECURITY THREATS). */

On Mon, 31 May 2004 13:32:04 -0500, Clifford Kite wrote:
> Alex Meov <(E-Mail Removed)> wrote:
>> My mini-network consists of a Linux firewall (Debian,
>> 2.4.22 kernel, masquerading with iptables) and the main
>> workstation (Linux/Windows). The firewall has 2 NICs:
>> one (eth0, 10.11.1.119) connected to the ISP's network through
>> a cable modem; another NIC (eth1, 192.168.0.1) is connected to
>> the workstation. The workstation has one NIC (192.168.0.2).
>>
>> The firewall seems to be working, i.e. one cannot connect
>> to 192.168.0.2 or ping it from the outside. However, one CAN see
>> and ping 192.168.0.1 from the ISP's 10.11.X.X network. This,
>> understandably, makes the ISP unhappy (they did check that they
>> are pinging my box and not someone else's 192.168.0.1 by looking
>> at MAC addresses).
>
> I think the only way that a ping echo-request, sent from an ISP host
> on 10.11.0.0/16 (?), can elicit an echo-reply from 192.168.0.1 is for
> your Internet connection host to respond with the MAC address of eth1
> in an ARP reply to an ARP who-has 192.168.0.1 request by the ISP host.
Thank you!! That was a perfect diagnosis. Logging all traffic
on eth0 (external interface) for a few days found no mention
of 192.168.0.X except
ISP: arp who-has 192.168.0.1 tell ISP's.router.IP
my firewall: arp reply 192.168.0.1 is-at my:mac:address

I am now using arptables to block unwanted outgoing ARP packets
on eth0 and has heard from the ISP that the problem went away:

# arptables -L -v
Chain INPUT (policy ACCEPT 79779 packets, 2234K bytes)

Chain OUTPUT (policy DROP 10 packets, 280 bytes)
-j ACCEPT -i any -o eth1 , pcnt=290 -- bcnt=8120
-j ACCEPT -i any -o eth0 -s 10.0.0.0/8 , pcnt=329 -- bcnt=9212

> You can try this:
>
> /sbin/ifconfig eth0 -arp
....
> No guarantee, I'm not really certain this will work but certainly
> would like to know whether or not it does.
It did not provide an easy solution -- just running
"/sbin/ifconfig eth0 -arp" stopped all traffic to/from the ISP,
since when ISP's gateway information expired from my firewall's cache
it did not know where to send data. I started thinking of the
workarounds that do not require hard-coding ISP host's MAC, but then
found arptables and decided not to reinvent the wheel.

Again, thanks for the help!

--
Best regards,
Alex

Alex Meov <(E-Mail Removed)> wrote:
> On Mon, 31 May 2004 13:32:04 -0500, Clifford Kite wrote:

>> You can try this:
>>
>> /sbin/ifconfig eth0 -arp
> ...
>> No guarantee, I'm not really certain this will work but certainly
>> would like to know whether or not it does.
> It did not provide an easy solution -- just running
> "/sbin/ifconfig eth0 -arp" stopped all traffic to/from the ISP,
> since when ISP's gateway information expired from my firewall's cache
> it did not know where to send data. I started thinking of the
> workarounds that do not require hard-coding ISP host's MAC, but then
> found arptables and decided not to reinvent the wheel.

> Again, thanks for the help!

Thank YOU for this reply! After I posted, it dawned on me that the
-arp suggestion might well stop traffic from the ISP traffic too and
thus your Internet access. I've been trying to figure another way
ever since but without success.

I've never heard of arptables, but will certainly take a look at it
now to see what's involved, and won't forget how valuable an asset
it can be.

Thanks again too.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */