| 1 |
On 22 September 2011 12:39, Adam Carter <adamcarter3@×××××.com> wrote: |
| 2 |
> # tcpdump -n -i eth0 host 192.168.1.6 and port not 22 |
| 3 |
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode |
| 4 |
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes |
| 5 |
> 21:10:57.011994 IP 192.168.1.6.46161 > 192.168.1.250.80: S |
| 6 |
> 4279617058:4279617058(0) win 14600 <mss 1460,sackOK,timestamp 7007662 |
| 7 |
> 0,nop,wscale 6> |
| 8 |
> 21:10:57.037227 IP 192.168.1.250 > 192.168.1.6: ICMP host |
| 9 |
> 192.168.1.250 unreachable - admin prohibited filter, length 36 |
| 10 |
|
| 11 |
> Anyone seen this behavior? There's no iptables, the hosts are gentoo |
| 12 |
> and on the same subnet. I've only seen admin prohibited ICMP from |
| 13 |
> filtering by cisco ACLs - what could be the problem? |
| 14 |
|
| 15 |
It's not the ICMP that is being prohibited. This packet: |
| 16 |
|
| 17 |
> 21:10:57.037227 IP 192.168.1.250 > 192.168.1.6: ICMP host |
| 18 |
> 192.168.1.250 unreachable - admin prohibited filter, length 36 |
| 19 |
|
| 20 |
is an ICMP "host unreachable" response from .250. The extended reason |
| 21 |
for the unreachability is that there is an administrative policy |
| 22 |
preventing the traffic. It almost certainly *is* a firewall that's |
| 23 |
preventing this, one with a REJECT target, as REJECT specifies to |
| 24 |
return an ICMP unreachable packet. I suggest that you look more |
| 25 |
closely at the firewalling on .250. If there is definitely no |
| 26 |
firewalling going on (ie iptables -nvL shows only default policies and |
| 27 |
the default is ACCEPT for INPUT and OUTPUT chains) then could there be |
| 28 |
an intervening network device? |
| 29 |
|
| 30 |
Rich |
Archives