Internal ip exiting network on firewall external nic despight rule

Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

I'm not sure I understand this data that I'm getting from my firewall.
If I understand it correctly it's saying that a machine from my local
net is going out through my external Interface.  I have a rule which
should drop all internal network request that appear at the external
nic. Any help would be appreciated.

RULE ####
# remote interface, claiming to be local machines, IP spoofing, get lost
#
$IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j drop-and-log-it

CONFIG ###
s3a-www:~ # firewall mlist
  External Interface:  eth1
  Internal Interface:  eth0
  ---
  External IP: **.**.76.66
  ---
  Internal Network: 192.168.1.0/24
  Internal IP:      192.168.1.1



LOG FILE ###
Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105
DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF
PROTO=TCP SPT=4380 DPT=110 WI
NDOW=8760 RES=0x00 ACK URGP=0
 
Rowan Reid
Job Captain, 
Systems Administrator
STUDIO 3 ARCHITECTS
909  982  1717

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 7:37 pm, Rowan Reid wrote:

> I'm not sure I understand this data that I'm getting from my firewall.
> If I understand it correctly it's saying that a machine from my local
> net is going out through my external Interface.  I have a rule which
> should drop all internal network request that appear at the external
> nic. Any help would be appreciated.
>
> RULE ####
> # remote interface, claiming to be local machines, IP spoofing, get lost
> #
> $IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j drop-and-log-it

The "-d $UNIVERSE" is redundant here:

1. It's redundant in any rule - leave it out and the meaning is the same.
2. You don't need to specify destination address in the INPUT chain because 
it has to be an address on the firewall - can't be anything else.

> CONFIG ###
> s3a-www:~ # firewall mlist
>   External Interface:  eth1
>   Internal Interface:  eth0
>   ---
>   External IP: **.**.76.66
>   ---
>   Internal Network: 192.168.1.0/24
>   Internal IP:      192.168.1.1
>
> LOG FILE ###
> Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105
> DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF
> PROTO=TCP SPT=4380 DPT=110 WINDOW=8760 RES=0x00 ACK URGP=0

You're correct that this log entry shows a packet with source address 
192.168.1.105 entering your firewall on eth1, however what I don't understand 
it why it would be picked up by a rule in your INPUT chain, because this 
packet is not destined for the firewall itself - it is destined for machine 
216.99.233.76 chimmx04.algx.net, and should therefore be passing through your 
FORWARD chain (even if it does come in and go out the same interface, it'll 
still go through the FORWARD chain).

The packet is trying to connect to chimmx04.algx.net on port 110, which is 
pop3, and that machine is indeed running a pop3 server - it claims to be a 
Messaging Multiplexor running iPlanet Messaging Server 5.1

Do you have a machine with address 192.168.1.105 on your internal network ?

Maybe you could show us the rest of your ruleset, in particular any nat rules 
you've set up - also perhaps explain your network configuration more fully - 
what is eth1 actually connected to - is it just a router / ADSL / cable modem 
/ whatever to the outside world, or is there anything else on the external 
side of the firewall ?

Antony.

-- 

How I want a drink, alcoholic of course, after the heavy chapters
involving quantum mechanics.

 - 3.14159265358979

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

> Rowan Reid wrote:
> 
> > 
> > LOG FILE ###
> > Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105 
> > DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF 
> > PROTO=TCP SPT=4380 DPT=110 WI NDOW=8760 RES=0x00 ACK URGP=0
> 
> Note that IN and OUT both indicate eth1 -- do you perhaps 
> have both NICs 
> connected to the same hub/switch?
> 

Yes, however my Rules are such that eth1 (External) should regect and
log external machines with an internal net address.
# remote interface, claiming to be local machines, IP spoofing, get lost
# $IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j
drop-and-log-it
Also all machines are configured such that the internal nic address
192.168.1.1 is the only gateway. Me detects a fish! My ifconfig output
Is below.

eth0      Link encap:Ethernet  HWaddr 00:04:75:B1:3D:A9
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67496 errors:0 dropped:0 overruns:0 frame:0
          TX packets:88214 errors:0 dropped:0 overruns:0 carrier:0
          collisions:5813 txqueuelen:100
          RX bytes:5334404 (5.0 Mb)  TX bytes:101576923 (96.8 Mb)
          Interrupt:11 Base address:0x6100

eth1      Link encap:Ethernet  HWaddr 00:04:75:B1:3D:6C
          inet addr:**.**.76.66  Bcast:65.45.76.71  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:51089 errors:0 dropped:0 overruns:1 frame:0
          TX packets:41940 errors:0 dropped:0 overruns:0 carrier:0
          collisions:10 txqueuelen:100
          RX bytes:37129813 (35.4 Mb)  TX bytes:4338695 (4.1 Mb)
          Interrupt:10 Base address:0x6200

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1374 (1.3 Kb)  TX bytes:1374 (1.3 Kb)

Re: Internal ip exiting network on firewall external nic despight rule

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Rowan Reid wrote:

> 
> LOG FILE ###
> Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105
> DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF
> PROTO=TCP SPT=4380 DPT=110 WI
> NDOW=8760 RES=0x00 ACK URGP=0

Note that IN and OUT both indicate eth1 -- do you perhaps have both NICs 
connected to the same hub/switch?

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3257 bytes --]

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 8:11 pm, Rowan Reid wrote:

> > Rowan Reid wrote:
> > > LOG FILE ###
> > > Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105
> > > DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF
> > > PROTO=TCP SPT=4380 DPT=110 WI NDOW=8760 RES=0x00 ACK URGP=0
> >
> > Note that IN and OUT both indicate eth1 -- do you perhaps
> > have both NICs connected to the same hub/switch?
>
> Yes,

Ugh !!!   This is a horrible way to connect a firewall.....    Why ????

Antony.

-- 

In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

Re: Internal ip exiting network on firewall external nic despight rule

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

Rowan Reid wrote:
>>Rowan Reid wrote:
>>
>>
>>>LOG FILE ###
>>>Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105 
>>>DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF 
>>>PROTO=TCP SPT=4380 DPT=110 WI NDOW=8760 RES=0x00 ACK URGP=0
>>
>>Note that IN and OUT both indicate eth1 -- do you perhaps 
>>have both NICs 
>>connected to the same hub/switch?
>>
> 
> 
> Yes, however my Rules are such that eth1 (External) should regect and
> log external machines with an internal net address.
> # remote interface, claiming to be local machines, IP spoofing, get lost
> # $IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j
> drop-and-log-it

But the packet logged above never goes near the INPUT flter table chain -- 
it goes through the FORWARD chain. Once you plug that hole then you'll 
start having stalls due to the way that the Linux kernel handles ARP 
who-has requests (the response can come from any interface connected to 
the switch/hub). There was a solution for this problem on the 2.2 kernels 
('hidden' interface flag) but last time that I researched it, there was no 
solution on 2.4. Someone correct me please if I'm wrong about that...

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3257 bytes --]

Re: Internal ip exiting network on firewall external nic despight rule

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

Antony Stone wrote:
>>>
>>>Note that IN and OUT both indicate eth1 -- do you perhaps
>>>have both NICs connected to the same hub/switch?
>>
>>Yes,
> 
> 
> Ugh !!!   This is a horrible way to connect a firewall.....    Why ????
> 

Seems like lots of people try to build test beds this way and given the 
way that the Linux kernel handles ARP, these folks end up very confused....

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3257 bytes --]

Re: Internal ip exiting network on firewall external nic despight rule

[Alistair Tonner]

	The question really is what device is on the other end of eth1.
	If this device could concievably misroute an internal packet, 
you
	need to look at the device with ip 192.168.1.105 (if its on 
your network)
	and make sure it hasn't mucked up its default gateway.

	if eth1 is *only* connected to the outside world you should 
just drop
	packets like this as martians... as that is what they are...
	echo 1> /proc/sys/net/ipv4/conf/eth1/log_martians
	will log the packet as just that.
	echo 1> /proc/sys/net/ipv4/conf/eth1/rp_filter 	will make the 
kernel verify the packet by reversed path.
	 
	Personally I have a rule in iptables that simply drops all known
	private segments coming in my outside interface.  period.

On 2002.09.20 15:11 Rowan Reid wrote:
> 
> > Rowan Reid wrote:
> >
> > >
> > > LOG FILE ###
> > > Sep 20 04:04:01 s3a-www kernel: IN=eth1 OUT=eth1 SRC=192.168.1.105
> 
> > > DST=216.99.233.76 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=61116 DF
> > > PROTO=TCP SPT=4380 DPT=110 WI NDOW=8760 RES=0x00 ACK URGP=0
> >
> > Note that IN and OUT both indicate eth1 -- do you perhaps
> > have both NICs
> > connected to the same hub/switch?
> >
> 
> Yes, however my Rules are such that eth1 (External) should regect and
> log external machines with an internal net address.
> # remote interface, claiming to be local machines, IP spoofing, get
> lost
> # $IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j
> drop-and-log-it
> Also all machines are configured such that the internal nic address
> 192.168.1.1 is the only gateway. Me detects a fish! My ifconfig output
> Is below.
> 
> eth0      Link encap:Ethernet  HWaddr 00:04:75:B1:3D:A9
>           inet addr:192.168.1.1  Bcast:192.168.1.255
> Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:67496 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:88214 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:5813 txqueuelen:100
>           RX bytes:5334404 (5.0 Mb)  TX bytes:101576923 (96.8 Mb)
>           Interrupt:11 Base address:0x6100
> 
> eth1      Link encap:Ethernet  HWaddr 00:04:75:B1:3D:6C
>           inet addr:**.**.76.66  Bcast:65.45.76.71
> Mask:255.255.255.248
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:51089 errors:0 dropped:0 overruns:1 frame:0
>           TX packets:41940 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:10 txqueuelen:100
>           RX bytes:37129813 (35.4 Mb)  TX bytes:4338695 (4.1 Mb)
>           Interrupt:10 Base address:0x6200
> 
> lo        Link encap:Local Loopback
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>           RX packets:13 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:1374 (1.3 Kb)  TX bytes:1374 (1.3 Kb)
> 
> 
> 

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

 your firewall on eth1, however what I 
> don't understand 
> it why it would be picked up by a rule in your INPUT chain, 
> because this 


I should have mentioned the internal machine is masquaraded. Therefore
It should go to the input chain no ?


> packet is not destined for the firewall itself - it is 
> destined for machine 
> 216.99.233.76 chimmx04.algx.net, and should therefore be 
> passing through your 
> FORWARD chain (even if it does come in and go out the same 
> interface, it'll 
> still go through the FORWARD chain).

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

http://www.e-infomax.com/ipmasq/howto/examples/rc.firewall-2.4-stronger

My firewall ruleset is a slight modification of the above link.

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 9:59 pm, Rowan Reid wrote:

> > don't understand
> > why it would be picked up by a rule in your INPUT chain,
> > because this
>
> I should have mentioned the internal machine is masquaraded. Therefore
> It should go to the input chain no ?

The INPUT chain is for packets addressed to the firewall itself.

The FORWARD chain is for packets going through the firewall to some other 
machine.

Destination NAT is performed in the PREROUTING chain, which comes before 
either INPUT or FORWARD, therefore it is the "real" destination which 
determines whether a packet traverses the INPUT or the FORWARD chain.

Antony.

-- 

Success is a lousy teacher.   It seduces smart people into thinking they 
can't lose.

 - William H Gates III

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 10:01 pm, Rowan Reid wrote:

> > Ugh !!!   This is a horrible way to connect a firewall.....
> >  Why ????
> >
> > Antony.
>
> I realize this, the reason being is there are other machines that have
> public IP's specifically my VPN. Since I have found no stable support
> for Masquarading VPN traffic

Sounds like you're using the wrong sort of VPN.   IPsec has very successful 
and stable support under Linux, works well through netflter, including under 
NAT, and the FreeS/WAN implementation works well with other vendors'ystems on 
the remote gateway.

If you're trying to use PPTP then I agree you'll have problems.

> I placed it on the external net. Which is
> basically a hub sharing my T1 my firewall and VPN machine.

That does not explain why you would even consider plugging both the internal 
and external interfaces of your firewall into the same switch / hub.

If you have other machines which require a public IP address, and which you 
do not want to NAT, then you have a switch / hub on the external interface of 
your firewall, connecting together anything which has a genuine public IP 
address (eg router, firewall, VPN gateway).

Then you have a different switch / hub on the internal interface of your 
firewall, joining it to all the machines on your internal network.   The 
firewall is the only physical connection between the inside and the outside, 
therefore it can act as a filter to decide what traffic is allowed and what 
isn't.

If you do not physically separate the internal and external networks (eg you 
join them to the same switch / hub) you will have problems.

Antony.

-- 

The difference between theory and practice is that
in theory there is no difference, whereas in practice there is.

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 10:24 pm, Rowan Reid wrote:

> http://www.e-infomax.com/ipmasq/howto/examples/rc.firewall-2.4-stronger
>
> My firewall ruleset is a slight modification of the above link.

From what you have said so far, I don't think your ruleset is the problem 
(except possibly for a certain misunderstanding about the difference between 
INPUT and FORWARD chains...?).

I just had a look at that ruleset, and I'm very surprised at the use of 
$UNIVERSE all over the place - as I mentioned in a previous mail in this 
thread, it is quite redundant no matter where it appears (in other words, 
leaving it out of any rule creates precisely the same meaning, and is 
generally easier to understand), and in several of the examples where it 
appears it is actually rather pointless, eg:

iptables -A INPUT -s $somewhere -d $universe -j DROP

There is absolutely no purpose in having $universe (= 0.0.0.0/0) in such a 
rule.


I think the problem is your physical network setup - you should not have a 
direct link between the internal and external interfaces of your firewall.

Antony.

-- 

Most people are aware that the Universe is big.

 - Paul Davies, Professor of Theoretical Physics

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

> >
> > I should have mentioned the internal machine is 
> masquaraded. Therefore 
> > It should go to the input chain no ?
> 
> The INPUT chain is for packets addressed to the firewall itself.
> 
> The FORWARD chain is for packets going through the firewall 
> to some other 
> machine.
> 
> Destination NAT is performed in the PREROUTING chain, which 
> comes before 
> either INPUT or FORWARD, therefore it is the "real" destination which 
> determines whether a packet traverses the INPUT or the FORWARD chain.
> 

Just when I thought I understood. So returning masqaraded traffic hits
the input rule set no ? Then gets routed through POSTROUTING is it then
routed to the forward ruleset, or is it just sent out. What I'm
realizing is to stop internal machines from accessing the external
interface I need to put drop rule for all insternal traffic on the
FORWARD chain such as below ?

$IPTABLES -A INPUT -i $EXTIF -s $INTNET -d $UNIVERSE -j drop-and-log-it
$IPTABLES -A FORWARD -i $EXTIF -s $INTNET -d $UNIVERSE -j
drop-and-log-it

Then figure out why exactly my local net machines are accessing my
external IP to exit the net. This confuses me because all these machines
are setup with the gateway being the internal ip
(192.168.1.1/255.255.255.0) as the gateway so these machines shouldn't
even know my external ip/interface exists.

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

> I think the problem is your physical network setup - you 
> should not have a 
> direct link between the internal and external interfaces of 
> your firewall.


True, but shouldn't I be able to separate the networks using subnets
check out my setup below


Internal Net

DHCP assignes settings below also internet DNS

Network 192.168.1.0
Subnet  255.255.255.0
Gateway 192.168.1.1



Firewall 

Internal Interface 192.168.1.1
Subnet             255.255.255.0
External Interface  **.**.76.66
Subnet             255.255.255.248 (ISP Assigned)
Internet Gateway    **.**.76.65


Since I'm cheap I don’t want to purchase another hub, I have my T1,
connected to a hub with my Firewall extif, my VPN extif and the hub is
connected to my switch this allows my to access the net directly and
through the firewall from my station, this is for diagnostic purposes so
I don’t have to play cable switcher. 

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 10:58 pm, Rowan Reid wrote:

> > The INPUT chain is for packets addressed to the firewall itself.
> > The FORWARD chain is for packets going through the firewall
> > to some other machine.
> >
> > Destination NAT is performed in the PREROUTING chain, which comes
> > before either INPUT or FORWARD, therefore it is the "real" destination
> > which determines whether a packet traverses the INPUT or the FORWARD
> > chain.
>
> Just when I thought I understood. So returning masqaraded traffic hits
> the input rule set no ?

No :-)

> Then gets routed through POSTROUTING

No :-)

> is it then routed to the forward ruleset, or is it just sent out.

Okay - this is how it works:

The *original* packet (the first one) in what is going to be a natted 
connection gets to the firewall, enters the PREROUTING chain, and the 
destination address gets changed.   The packet then goes on to the FORWARD 
chain (where it might get blocked, but in this example is allowed through), 
goes on further to the POSTROUTING chain, where nothing happens to it in our 
example, and it then exits the machine and goes to the real destination.

Something which is not obvious happened in the middle of that - when the 
packet went through the PREROUTING chain and the destination address got 
changed, an entry got placed in the connection tracking table to say where 
the packet came from and where it was going to, so that reply packets (which 
have the source & destination addresses the other way round) will get 
recognised when they come back through the firewall.....

So, sometime a little later on, a reply packet comes back.   Immediately it 
gets to the PREROUTING chain (before it traverses any rules) it gets 
recognised as a reply packet to an existing connection, and it simply 
bypasses the nat rules in the PREROUTING chain, goes through the normal rules 
in the FORWARD chain (hopefully gets matched by the first rule, which is for 
ESTABLISHED,RELATED packets), and then gets automagically reverse-natted 
instead of going through any rules you might have put in the POSTROUTING 
chain, so that the source address is now whatever the destination address of 
the first packet was.

Basically what this all means is:

1. You do not have to specify nat rules to process reply packets - the 
reverse of the rules you specified for the outgoing packets will 
automatically be applied.

2. You *cannot* specify nat rules to process reply packets - because they 
bypass the rules in the nat chains as soon as they are recognised as reply 
packets by the entry in the connection tracking table.

> What I'm realizing is to stop internal machines from accessing the external
> interface I need to put drop rule for all internal traffic on the FORWARD
> chain such as below ?

Correct.

The rules are quite simple:

1. The INPUT chain is *only* for packets which terminate on this machine.

2. The FORWARD chain is *only* for packets which are going through this 
machine.

3. The OUTPUT chain is *only* for packets which originate on this machine.

If you have seen diagrams of the way ipchains used to work, where some 
packets would go through all three of the INPUT, FORWARD and OUTPUT chains, 
then forget it - iptables does not work like that.

If you have not seen those diagrams, then do not be distracted by the INPUT 
chain or think "packets have to come IN to this machine even if they're then 
going to go OUT again" - the rule is that packets which go *through* a 
netfilter box traverse the FORWARD chain but do not traverse either the INPUT 
or the OUTPUT chains.

> Then figure out why exactly my local net machines are accessing my
> external IP to exit the net. This confuses me because all these machines
> are setup with the gateway being the internal ip
> (192.168.1.1/255.255.255.0) as the gateway so these machines shouldn't
> even know my external ip/interface exists.

You have physically plugged the internal and external interfaces of your 
firewall into the same switch / hub, therefore the machines on your internal 
network are plugged into your external interface, and unfortunately Linux 
responds to ARP requests in ways you might not expect....  (I think Tom 
Eastep mentioned this in an earlier posting).

Connect your external interface to your Internet link, using a switch / hub 
which also has any other machines with true (non-nat) public IPs.

Connect your internal interface to your internal LAN, using another switch / 
hub which is not connected to anything with a true public IP.

Then let us know if you have any further problems.

Antony.

-- 

There are only 10 types of people in the world:
those who understand binary notation,
and those who don't.

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Friday 20 September 2002 11:26 pm, Rowan Reid wrote:

> > I think the problem is your physical network setup - you should not have a
> > direct link between the internal and external interfaces of your firewall.
>
> True, but shouldn't I be able to separate the networks using subnets

No, not the way you might think.

I agree that everything you have put in your ruleset (except for the 
misunderstanding about INPUT vs. FORWARD, which I think we've now sorted 
out), makes sense and looks like it ought to work, but only if you physically 
separate your networks.

If you do not use two separate switches / hubs for the internal & external 
interfaces of your firewall, then it will not behave the way you expect it to.

> Since I'm cheap I don?t want to purchase another hub, I have my T1....

You have a T1 connections and you don't want to pay for another hub ?

Okay, but don't be surprised if your firewall doesn't work like that....

Sorry.

Antony.

-- 

It is also possible that putting the birds in a laboratory setting
inadvertently renders them relatively incompetent.

 - Daniel C Dennett

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

> > Just when I thought I understood. So returning masqaraded 
> traffic hits 
> > the input rule set no ?
> 
> No :-)

Dooope !!

> 
> > Then gets routed through POSTROUTING
> 
> No :-)

Doooope !!!
> 
> > is it then routed to the forward ruleset, or is it just sent out.
> 
> Okay - this is how it works:
> 
> The *original* packet (the first one) in what is going to be a natted 
> connection gets to the firewall, enters the PREROUTING chain, and the 
> destination address gets changed.   The packet then goes on 
> to the FORWARD

So it gets nated at the PREROUTING chain oooooooohhhhhhhh ...
> 1. The INPUT chain is *only* for packets which terminate on 
> this machine.
> 
> 2. The FORWARD chain is *only* for packets which are going 
> through this 
> machine.
> 
> 3. The OUTPUT chain is *only* for packets which originate on 
> this machine.


Ooooooooooooohhhhhhhhhhhhhhhhhhhhhhhhh !!

> 
> > Then figure out why exactly my local net machines are accessing my 
> > external IP to exit the net. This confuses me because all these 
> > machines are setup with the gateway being the internal ip
> > (192.168.1.1/255.255.255.0) as the gateway so these 
> machines shouldn't 
> > even know my external ip/interface exists.
> 
> You have physically plugged the internal and external 
> interfaces of your 
> firewall into the same switch / hub, therefore the machines 
> on your internal 
> network are plugged into your external interface, and 
> unfortunately Linux 
> responds to ARP requests in ways you might not expect....  (I 
> think Tom 
> Eastep mentioned this in an earlier posting).
> 
> Connect your external interface to your Internet link, using 
> a switch / hub 
> which also has any other machines with true (non-nat) public IPs.

Oohh ok .. Well

Thank you thank you thank you thank you thank you, for your time I
appreciate that .. Domo arigato genious san.

<action> 
Goes back to my mlafunctioned misconfigured linux box 
</action>

RE: Internal ip exiting network on firewall external nic despight rule

[Rowan Reid]

> > Since I'm cheap I don?t want to purchase another hub, I 
> have my T1....
> 
> You have a T1 connections and you don't want to pay for another hub ?

Why do you think I can't afford a hub, actually kudoes to Allegience
Telecom
$300 a month = T1 (6 phone lines and a 500K dedicated connection 16IP's)
Tell em Rowan sent ya!




> Okay, but don't be surprised if your firewall doesn't work 
> like that....
> 
<action>
Kicks his networking for dummies book out the window
</action>

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

Hi.

I just thought I'd clarify something which I might have mis-assumed, based on 
what you said in your last reply:

On Saturday 21 September 2002 12:10 am, Rowan Reid wrote:

> > Okay - this is how it works:
> >
> > The *original* packet (the first one) in what is going to be a natted
> > connection gets to the firewall, enters the PREROUTING chain, and the
> > destination address gets changed.   The packet then goes on
> > to the FORWARD
>
> So it gets nated at the PREROUTING chain oooooooohhhhhhhh ...

Destination NAT (which is what I've assumed is going here - maybe 
incorrectly) is done in the PREROUTING chain.

Source NAT (which maybe is what you're doing ?) is done in the POSTROUTING 
chain.

However, apart from that difference, everything else I said is correct for 
either situation:

1. Reply packets for NATted connections always bypass any rules in both the 
PREROUTING and POSTROUTING chains, and simply get automagically 
reverse-natted according to whatever the original nat rule was.

2. If the original packet got DNATted in the PREROUTING chain, then the reply 
packet gets automagically SNATted at the POSTROUTING stage (ie after going 
through the FORWARD chain).

3. If the original packet got SNATted in the POSTROUTING chain, then the 
reply packet gets automagically DNATted at the PREROUTING stage (ie before 
going through the FORWARD chain).

4. The FORWARD chain should always contain rules whcih relate to the "real" 
source & destination addresses, no matter what DNAT may have already 
occurred, or what SNAT may be about to occur.

5. What I said about whether packets go through INPUT, OUTPUT or FORWARD was 
accurate in all situations.

Hope this helps.

Antony.

-- 

Normal people think "if it ain't broke, don't fix it".
Engineers think "if it ain't broke, it doesn't have enough features yet".

Re: Internal ip exiting network on firewall external nic despight rule

[Antony Stone]

On Saturday 21 September 2002 12:13 am, Rowan Reid wrote:

> > > Since I'm cheap I don?t want to purchase another hub, I
> > > have my T1....
> >
> > You have a T1 connection and you don't want to pay for another hub ?
>
> Why do you think I can't afford a hub, actually kudoes to Allegience
> Telecom $300 a month = T1 (6 phone lines and a 500K dedicated connection
> 16IP's)

Well, round these parts I can buy an 8 port switching hub for £21.95 = ~$30

> > Okay, but don't be surprised if your firewall doesn't work
> > like that....
>
> <action>
> Kicks his networking for dummies book out the window
> </action>

Are you telling me that you have a network book which says it's okay to plug 
both the internal & external interfaces of a firewall into the same switch / 
hub (or does it simply not say that it isn't okay....) ?

Antony.

-- 

Which part of 'apt-get dist-upgrade' do you not understand ???

Re: Internal ip exiting network on firewall external nic despight rule

[Tom Eastep]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Rowan Reid wrote:
> <action>
> Kicks his networking for dummies book out the window
> </action>
> 

You really should if the book advocates a one-hub test bed for a Linux 
firewall; that just plain doesn't work. That advice is mentioned several 
times on my site (URL below)....

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
AIM: tmeastep  \ http://www.shorewall.net
ICQ: #60745924  \ teastep@shorewall.net

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3257 bytes --]

Re: Internal ip exiting network on firewall external nic despight rule

[Anders Fugmann]

Rowan Reid wrote:
> Since I'm cheap I don’t want to purchase another hub, I have my T1,
> connected to a hub with my Firewall extif, my VPN extif and the hub is
> connected to my switch this allows my to access the net directly and
> through the firewall from my station, this is for diagnostic purposes so
> I don’t have to play cable switcher. 
I really do not understand why you do not want all traffic to go through 
your firewall. A firewall is supposed to shield off any unwanted traffic 
to ever enter the internal network, which is only accomplised, if all 
traffic _must_ go through the firewall.

This could be accomplished simply by connecting your external interface 
on the firewall directly to the T1 entry point, and the switch/hub to 
the internal network interface.

The "diagnostic purposes" you are talking about are rendered useless 
with the configuraion you are describing - not to mention the _serious_ 
degradation of your network.

Regards
Anders Fugmann