1 |
> It's not the ICMP that is being prohibited. |
2 |
|
3 |
Understood, that's clear from the packet trace. |
4 |
|
5 |
> is an ICMP "host unreachable" response from .250. The extended reason |
6 |
> for the unreachability is that there is an administrative policy |
7 |
> preventing the traffic. It almost certainly *is* a firewall that's |
8 |
> preventing this, one with a REJECT target, as REJECT specifies to |
9 |
> return an ICMP unreachable packet. |
10 |
|
11 |
Most firewalls i've seen send a spoofed TCP reset, not an ICMP when |
12 |
rejecting TCP. However, iptables can do either. I have run iptables -F |
13 |
and the tables are shown as clear with iptables -L. |
14 |
|
15 |
proxy vhosts.d # iptables -L |
16 |
Chain INPUT (policy ACCEPT) |
17 |
target prot opt source destination |
18 |
|
19 |
Chain FORWARD (policy ACCEPT) |
20 |
target prot opt source destination |
21 |
|
22 |
Chain OUTPUT (policy ACCEPT) |
23 |
target prot opt source destination |
24 |
|
25 |
Chain fail2ban-SSH (0 references) |
26 |
target prot opt source destination |
27 |
|
28 |
Chain fail2ban-apache (0 references) |
29 |
target prot opt source destination |
30 |
proxy vhosts.d # |
31 |
|
32 |
> I suggest that you look more |
33 |
> closely at the firewalling on .250. If there is definitely no |
34 |
> firewalling going on (ie iptables -nvL shows only default policies and |
35 |
> the default is ACCEPT for INPUT and OUTPUT chains) then could there be |
36 |
> an intervening network device? |
37 |
|
38 |
The devices are connected, there's only a switch between them (a |
39 |
billion ADSL router). |