Board index Linux Networking

ping from behind firewall, but not on firewall

ping from behind firewall, but not on firewall

Post by Jeffrey Baco » Tue, 27 Nov 2001 09:55:43



I have a wierd problem.  I have a linux box set up doing NAT/firewall for an
internal network. I can ping an address (carleton.ca) from machines behind my
firewall but not from my firewall box itself.  What might this indicate?

--
Jeff

 
 
 
Top

ping from behind firewall, but not on firewall

Post by Michael Guelf » Tue, 27 Nov 2001 16:58:21


This might indicate that you're running a 2.4.x kernel with ECN enabled.

From the squid FAQ:

    Some versions of linux implement Explicit Congestion Notification (ECN)
and
    this can cause some TCP connections to fail when contacting some sites
with
    broken firewalls or broken TCP/IP implementations.

    To work around such broken sites you can disable ECN with the following
    command:

    echo 0 >/proc/sys/net/ipv4/tcp_ecn

Then again, it might be some other issue ;)


Quote:> I have a wierd problem.  I have a linux box set up doing NAT/firewall for
an
> internal network. I can ping an address (carleton.ca) from machines behind
my
> firewall but not from my firewall box itself.  What might this indicate?

> --
> Jeff


 
 
 
Top

ping from behind firewall, but not on firewall

Post by Stephan A. Rickau » Tue, 27 Nov 2001 20:48:22


Moin,


> I have a wierd problem.  I have a linux box set up doing NAT/firewall for an
> internal network. I can ping an address (carleton.ca) from machines behind my
> firewall but not from my firewall box itself.  What might this indicate?

It might indicate that you set up your forwarding rulez correctly
(NAT) but not your OUTPUT queue (itc: icmp-type=echo-request), which
is responsible for packets _from_ the firewall itself . Further, the
related INPUT rule is mandatory (itc: icmp-type=echo-reply).

Stephan

 
 
 
Top

ping from behind firewall, but not on firewall

Post by Karl Heye » Tue, 27 Nov 2001 22:53:55



> This might indicate that you're running a 2.4.x kernel with ECN
> enabled.

> From the squid FAQ:

>     Some versions of linux implement Explicit Congestion
>     Notification (ECN)
> and
>     this can cause some TCP connections to fail when contacting some
>     sites
> with
>     broken firewalls or broken TCP/IP implementations.

>     To work around such broken sites you can disable ECN with the
>     following command:

>     echo 0 >/proc/sys/net/ipv4/tcp_ecn

> Then again, it might be some other issue ;)

ECN applies to TCP only, ping uses ICMP.  It is more likely that the
firewall is not responding to ICMP messages to forwards other packets
and possibly ICMP.

karl.

 
 
 
Top

ping from behind firewall, but not on firewall

Post by Karl Heye » Tue, 27 Nov 2001 22:50:52



> I have a wierd problem.  I have a linux box set up doing
> NAT/firewall for an internal network. I can ping an address
> (carleton.ca) from machines behind my firewall but not from my
> firewall box itself.  What might this indicate?

the firewall is forwarding packets but is not responding to at
least some ICMP types.  ipchains -L -n or iptables -L -n will
indicate that.

karl.

 
 
 
Top

ping from behind firewall, but not on firewall

Post by Michael Guelf » Wed, 28 Nov 2001 02:34:44




[...]
> ECN applies to TCP only, ping uses ICMP.  It is more likely that the
> firewall is not responding to ICMP messages to forwards other packets
> and possibly ICMP.

You would think so, except I've found that with it on I can't
ping/traceroute to affected hosts, with it turned off I have no problem.
 
 
 
Top

ping from behind firewall, but not on firewall

Post by Karl Heye » Wed, 28 Nov 2001 04:21:52






> [...]
>> ECN applies to TCP only, ping uses ICMP.  It is more likely that
>> the firewall is not responding to ICMP messages to forwards other
>> packets and possibly ICMP.

> You would think so, except I've found that with it on I can't
> ping/traceroute to affected hosts, with it turned off I have no
> problem.

hmmm.  There looks to be some ECN related fields in the IP flags
itself, but it doens't look like it get affected by tcp_ecn though.

The thing to check for is that you aren't getting caught out by
multiple IP addresses, and possibly multiple machines with the same
address.  some can be behind duff routers some may not.

traceroute uses UDP and ICMP.

karl.

 
 
 
Top

ping from behind firewall, but not on firewall

Post by Jeffrey Baco » Wed, 28 Nov 2001 11:00:26


I am using a script (MonMotha's Firewall v2.3.7
http://monmotha.mplug.org/firewall/index.php) to set up my firewall.  I don't
know much about the iptables stuff (was hoping to avoid it by using this nice
script) and MonMotha's email is bouncing on me so I can't get support there.

Does anyone have experience with this script?

I can't pick out a problem (as I only understand the basics) but here is the
output (slightly abreviated) from iptables -L -n :

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  192.168.0.0/24       0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
INETIN     all  --  0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  192.168.0.0/24       0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            192.168.0.0/24

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
INETOUT    all  --  0.0.0.0/0            0.0.0.0/0

Chain DMZIN (0 references)
target     prot opt source               destination

Chain DMZOUT (0 references)
target     prot opt source               destination

Chain INETIN (1 references)
target     prot opt source               destination
LDROP      all  --  0.0.0.0/0            0.0.0.0/0          state INVALID
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          icmp type 8 limit:
avg 5/sec burst 5
LDROP      icmp --  0.0.0.0/0            0.0.0.0/0          icmp type 8
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          icmp !type 8
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:20
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:21
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:22
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:25
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:53
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:80
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:113
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:119
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpt:143
UDPACCEPT  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:25
UDPACCEPT  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:53
UDPACCEPT  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:67
UDPACCEPT  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:113
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          state ESTABLISHED
TCPACCEPT  tcp  --  0.0.0.0/0            0.0.0.0/0          tcp dpts:1024:65535
state RELATED
UDPACCEPT  udp  --  0.0.0.0/0            0.0.0.0/0          udp dpts:1024:65535
state RELATED
LDROP      all  --  0.0.0.0/0            0.0.0.0/0

Chain INETOUT (1 references)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain LDROP (51 references)
target     prot opt source               destination
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `TCP Dropped '
LOG        udp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `UDP Dropped '
LOG        icmp --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `ICMP Dropped '
LOG        all  -f  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 4 prefix `FRAGMENT Dropped '
DROP       all  --  0.0.0.0/0            0.0.0.0/0

Chain LREJECT (0 references)
target     prot opt source               destination
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `TCP Rejected '
LOG        udp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `UDP Rejected '
LOG        icmp --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `ICMP Dropped '
LOG        all  -f  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 4 prefix `FRAGMENT Rejected '
REJECT     all  --  0.0.0.0/0            0.0.0.0/0          reject-with
icmp-port-unreachable

Chain LTREJECT (0 references)
target     prot opt source               destination
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `TCP Rejected '
LOG        udp  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `UDP Rejected '
LOG        icmp --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 6 prefix `ICMP Dropped '
LOG        all  -f  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 4 prefix `FRAGMENT Rejected '
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0          reject-with tcp-reset
REJECT     udp  --  0.0.0.0/0            0.0.0.0/0          reject-with
icmp-port-unreachable
DROP       icmp --  0.0.0.0/0            0.0.0.0/0
REJECT     all  --  0.0.0.0/0            0.0.0.0/0          reject-with
icmp-port-unreachable

Chain TCPACCEPT (23 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0          tcp flags:0x16/0x02
limit: avg 50/sec burst 5
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0          tcp flags:0x16/0x02
limit: avg 5/sec burst 5 LOG flags 0 level 4 prefix `Possible SynFlood '
LDROP      tcp  --  0.0.0.0/0            0.0.0.0/0          tcp flags:0x16/0x02
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0          tcp flags:!0x16/0x02
LOG        all  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 4 prefix `Mismatch in TCPACCEPT '
LDROP      all  --  0.0.0.0/0            0.0.0.0/0

Chain TREJECT (0 references)
target     prot opt source               destination
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0          reject-with tcp-reset
REJECT     udp  --  0.0.0.0/0            0.0.0.0/0          reject-with
icmp-port-unreachable
DROP       icmp --  0.0.0.0/0            0.0.0.0/0
REJECT     all  --  0.0.0.0/0            0.0.0.0/0          reject-with
icmp-port-unreachable

Chain UDPACCEPT (11 references)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0
LOG        all  --  0.0.0.0/0            0.0.0.0/0          limit: avg 5/sec
burst 5 LOG flags 0 level 4 prefix `Mismatch on UDPACCEPT '
LDROP      all  --  0.0.0.0/0            0.0.0.0/0

Karl Heyes wrote:
> On Mon, 26 Nov 2001 00:55:43 +0000, Jeffrey Bacon wrote:

>>I have a wierd problem.  I have a linux box set up doing
>>NAT/firewall for an internal network. I can ping an address
>>(carleton.ca) from machines behind my firewall but not from my
>>firewall box itself.  What might this indicate?

> the firewall is forwarding packets but is not responding to at
> least some ICMP types.  ipchains -L -n or iptables -L -n will
> indicate that.

> karl.

 
 
 
Top

1. FreeBSD and natd - routing from behind firewall to behind firewall.

Having a strange problem with a FreeBSD gateway/firewall system I set up.  
The gateway connects a small network to an ADSL line and has three static
external IP addresses.  I am using natd to provide access to the Internet
for computers in the internal LAN.

One of the machines behind the firewall is a web server and I use a natd
line similar to the following to route incoming connections to that box:

redirect_address 192.168.1.100 xxx.xxx.xxx.1

In this case the real IP of the web server is 192.168.1.100 and it is
accessed from outside the LAN by the address xxx.xxx.xxx.1.  This works.

The problem is that if any of the computers on the internal LAN try to
access the web server at xxx.xxx.xxx.1 it doesn't work.  I can access the
web server fine from inside the LAN using the local address (192.168.1.100).

I suspect there is a simple solution to this problem.  Can anyone explain
what it is?  

Thanks,
Don

2. Problem with the "int modify_ldt(int, void *, unsigned long)" function.

3. FTP server behind linux firewall communicating w/ FTP behind linux firewall

4. DE205 Net Card and linux network

5. firewall behind a firewall

6. Here's how excited HP is about Linux

7. IPChains firewall behind firewall problem

8. Software Installation Question

9. Fech behind a authenticated firewall (http firewall)

10. 2 servers, one won't ping from behind firewalls

11. FTP server behind on firewall FTP client behind another

12. FTP not working behind MASQ firewall

13. SMTP not working behind ip-masq firewall


All times are UTC
Board index