Re: DNAT working for one host but not another

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2016-12-05 at 07:04 +0000, Llorente Santos Jesus wrote:
> Hi Brian,
> 
> Did you try using the REDIRECT target instead?

I didn't before, but I just did and it doesn't seem to work either. 
Neither host gets ASSURED:

udp      17 26 src=10.75.23.212 dst=10.75.22.8 sport=6060 dport=23768 [UNREPLIED] src=10.75.22.247 dst=10.75.23.212 sport=5060 dport=6060 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp      17 28 src=10.75.22.200 dst=10.75.22.8 sport=6060 dport=23768 [UNREPLIED] src=10.75.22.8 dst=10.75.22.200 sport=23768 dport=6060 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1

and they both just keep getting ICMP port unreachable:

09:36:59.717222 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 472
09:36:59.717340 IP 10.75.22.8 > 10.75.23.212: ICMP 10.75.22.8 udp port 23768 unreachable, length 508
09:37:01.839127 IP 10.75.22.200.6060 > 10.75.22.8.23768: UDP, length 472
09:37:01.839212 IP 10.75.22.8 > 10.75.22.200: ICMP 10.75.22.8 udp port 23768 unreachable, length 508
09:37:03.718815 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 472
09:37:03.718921 IP 10.75.22.8 > 10.75.23.212: ICMP 10.75.22.8 udp port 23768 unreachable, length 508
09:37:05.218391 IP 10.75.22.200.6060 > 10.75.22.8.23768: UDP, length 0

There is definitely something listening on the port:

# netstat -pan | grep :5060
udp        0      0 10.75.22.8:5060         0.0.0.0:*                           32519/foo

But it really should work as a DNAT rule anyway.  It does for one host,
just not another.  And has worked as such for all hosts for many years.
 I just seems to have stopped working recently.

Interestingly enough, it seems that now, the host which can't move to
the ASSURED state is getting an ICMP port unreachable from the host:

09:20:47.041363 IP 10.75.22.200.6060 > 10.75.22.8.23768: UDP, length 471
09:20:47.041586 IP 10.75.22.8 > 10.75.22.200: ICMP 10.75.22.8 udp port 23768 unreachable, length 507

Yet the other host obviously managed to reach it:

udp      17 179 src=10.75.23.212 dst=10.75.22.8 sport=6060 dport=23768 src=10.75.22.8 dst=10.75.23.212 sport=5060 dport=6060 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp      17 26 src=10.75.22.200 dst=10.75.22.8 sport=6060 dport=23768 [UNREPLIED] src=10.75.22.8 dst=10.75.22.200 sport=23768 dport=6060 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1

I wonder if that sheds any more light on the problem.

Cheers,
b.

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux