[nmglug] iptables / routing question,

[Ed Brown]

Uncle.  As far as your .50 and .1 subnets go, the routes, eth configs, 
iptables seem ok (if you redid the src and destinations with /24).

Are you configuring appropriate gateways on your client systems? (1.1 
on the .1 subnet, and .50.1 on the .50).

Are the right cables plugged into eth0 and eth2?  Again, can you ping 
a system on each subnet from the firewall itself?  (You should be able 
to, according to your rules, which allow any OUTPUT.)

Do you have any mangling or nat-ing going on here? (cat 
/proc/net/ip_tables_names)

Try running two instances of tcpdump:
tcpdump -n -i eth0
tcpdump -n -i eth2
and doing things on those subnets that you think should and shouldn't 
work.  Does it get to the subnet-facing interface?  Does it get 
through the firewall and go out the destination-facing interface?

-ed


Andres Paglayan wrote:
> root at ipcop:~ # ip address show
> 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>     link/ether 00:60:08:31:dc:0c brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
> 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>     link/ether 00:10:4b:88:30:5d brd ff:ff:ff:ff:ff:ff
>     inet 192.168.2.1/24 brd 192.168.2.255 scope global eth1
> 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>     link/ether 00:01:02:66:7a:2e brd ff:ff:ff:ff:ff:ff
>     inet 192.168.50.1/24 brd 192.168.50.255 scope global eth2
> 5: eth3: <BROADCAST,UP> mtu 1500 qdisc htb qlen 1000
>     link/ether 00:20:78:e0:84:d7 brd ff:ff:ff:ff:ff:ff
>     inet 65.19.28.123/24 brd 65.19.28.255 scope global eth3
> 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1400 qdisc pfifo_fast qlen 
> 100
>     link/[65534]
>     inet 10.12.223.1 peer 10.12.223.2/32 scope global tun0
> 
> 
> On Dec 13, 2006, at 2:38 PM, Ed Brown wrote:
> 
>> 'ifconfig' output might be useful...
>>
>> Andres Paglayan wrote:
>>> what you do with dmz holes is allowing trafic from 50 (orange) to 
>>> enter 1 (green)
>>> by default, all trafic at 1 (green) should pass to 50 (or to 
>>> whichever else) with no further configuration
>>> (supposedly)
>>> what puzzles me now, is that the holes are correctly opened (so some 
>>> 50 ports can get to 1)
>>> but for some strange reason 1 can't get 50 (which is supposed to be 
>>> automatically opened)
>>> On Dec 13, 2006, at 1:19 PM, Ed Brown wrote:
>>>>
>>>> Andres Paglayan wrote:
>>>>> I'll re do that with /24,
>>>>> but there is already a DMZHOLES definition that is working, (from 
>>>>> there to here)
>>>>> I get the pings from 50 to 1 with no problems,
>>>>
>>>> Is that what you expect/want to be able to do?  If it is, I'm 
>>>> confused.  I thought the .50 is your DMZ, on eth2, which you wanted 
>>>> to restrict to only what is allowed in DMZHOLES...
>>>>
>>> _______________________________________________
>>> nmglug mailing list
>>> nmglug at nmglug.org
>>> http://www.nmglug.org/mailman/listinfo/nmglug
>>
>> _______________________________________________
>> nmglug mailing list
>> nmglug at nmglug.org
>> http://www.nmglug.org/mailman/listinfo/nmglug
> 
> 
> _______________________________________________
> nmglug mailing list
> nmglug at nmglug.org
> http://www.nmglug.org/mailman/listinfo/nmglug