[nmglug] iptables / routing question,

Andres Paglayan andres at paglayan.com
Wed Dec 13 15:44:05 PST 2006 

On Dec 13, 2006, at 3:35 PM, Ed Brown wrote:

> 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).

I concord, I re-did with /24 and configuration output looks the same

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

yep,

>
> 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.)
yep,
from the ipcop box I can ping any host at any subnet,
that's why I was thinking of an iptables superule to forward to eth2

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

root at ipcop:~ # cat /proc/net/ip_tables_names
mangle
filter
nat

>
> 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?
>

weird,

root at ipcop:~ # tcpdump -n -i eth2 |  grep 254
tcpdump: verbose output suppressed, use -v or -vv for full protocol  
decode
listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes
16:40:45.683806 IP 192.168.50.254 > 224.0.0.10:  eigrp 40
16:40:50.171288 IP 192.168.50.254 > 224.0.0.10:  eigrp 40
16:40:54.818047 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 0
16:40:55.110730 IP 192.168.50.254 > 224.0.0.10:  eigrp 40
16:40:55.818169 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 1
16:40:56.818366 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 2
16:40:57.818462 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 3
16:40:58.818660 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 4
16:40:59.446224 IP 192.168.50.254 > 224.0.0.10:  eigrp 40
16:40:59.818784 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 5
16:41:00.818893 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 6
16:41:01.819059 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 7
16:41:02.819222 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 8
16:41:03.819326 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 9
16:41:03.969694 IP 192.168.50.254 > 224.0.0.10:  eigrp 40
16:41:08.953148 IP 192.168.50.254 > 224.0.0.10:  eigrp 40

root at ipcop:~ # tcpdump -n -i eth0 | grep 254
tcpdump: verbose output suppressed, use -v or -vv for full protocol  
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 68 bytes
16:40:54.817956 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 0
16:40:55.818126 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 1
16:40:56.818300 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 2
16:40:57.818427 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 3
16:40:58.818627 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 4
16:40:59.818743 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 5
16:41:00.818855 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 6
16:41:01.819017 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 7
16:41:02.819185 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 8
16:41:03.377222 IP 204.134.81.3.443 > 192.168.1.91.2615: S  
1254935244:1254935244(0) ack 1656272408 win 16384 <mss  
1460,nop,nop,sackOK>
16:41:03.819279 IP 192.168.1.89 > 192.168.50.254: icmp 64: echo  
request seq 9
16:41:13.568209 IP 64.12.204.21.80 > 192.168.1.89.53584: P 20794:22254 
(1460) ack 547 win 6552
16:41:13.568874 IP 192.168.1.89.53584 > 64.12.204.21.80: . ack 22254  
win 65535
16:41:13.569910 IP 64.12.204.21.80 > 192.168.1.89.53584: P 22254:23714 
(1460) ack 547 win 6552
412 packets captured
412 packets received by filter
0 packets dropped by kernel


while
andres at mac:$ ping 192.168.50.254
PING 192.168.50.254 (192.168.50.254): 56 data bytes
^C
--- 192.168.50.254 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss



> -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
>
> _______________________________________________
> nmglug mailing list
> nmglug at nmglug.org
> http://www.nmglug.org/mailman/listinfo/nmglug

More information about the nmglug mailing list