* DNAT working for one host but not another
@ 2016-12-04 19:01 Brian J. Murrell
2016-12-04 19:06 ` Brian J. Murrell
0 siblings, 1 reply; 6+ messages in thread
From: Brian J. Murrell @ 2016-12-04 19:01 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
I have a DNAT rule on a host who's purpose is to redirect traffic that
is destined for port 23768 to port 5060 on that host:
Chain PREROUTING (policy ACCEPT 7340K packets, 362M bytes)
pkts bytes target prot opt in out source destination
9 3878 DNAT udp -- enp1s7 * 0.0.0.0/0 0.0.0.0/0 udp dpt:23768 to::5060
That rule seems to be working for one host but not another. This is
what I end up with in the conntrack table:
udp 17 29 src=10.75.22.8 dst=10.75.23.212 sport=5060 dport=6060 [UNREPLIED] src=10.75.23.212 dst=10.75.22.8 sport=6060 dport=5060 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp 17 175 src=10.75.22.200 dst=10.75.22.8 sport=6060 dport=23768 src=10.75.22.8 dst=10.75.22.200 sport=5060 dport=6060 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
udp 17 29 src=10.75.23.212 dst=10.75.22.8 sport=6060 dport=23768 [UNREPLIED] src=10.75.22.8 dst=10.75.23.212 sport=5060 dport=1024 mark=0 secctx=system_u:object_r:unlabeled_t:s0 use=1
So as you can see, 10.75.22.200 seems to be properly natted and moves
to the ASSURED state but the natting for 10.75.23.212 seems to get
confused and we end up with two of UNREPLIED entries.
Any idea what I'm doing wrong, or what is going wrong?
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT working for one host but not another
2016-12-04 19:01 DNAT working for one host but not another Brian J. Murrell
@ 2016-12-04 19:06 ` Brian J. Murrell
2016-12-05 7:04 ` Llorente Santos Jesus
0 siblings, 1 reply; 6+ messages in thread
From: Brian J. Murrell @ 2016-12-04 19:06 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Sun, 2016-12-04 at 14:01 -0500, Brian J. Murrell wrote:
> I have a DNAT rule on a host who's purpose is to redirect traffic
> that
> is destined for port 23768 to port 5060 on that host:
I should add, that what is going back to the 10.75.23.212 host is also
wrong:
14:04:53.723018 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 0
14:04:53.877539 IP 10.75.22.8.5060 > 10.75.23.212.6060: SIP, length: 555
14:04:53.910351 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 472
14:04:53.912158 IP 10.75.22.8.5060 > 10.75.23.212.6060: SIP, length: 555
As you can see, what is being returned is not having it's port un-
natted back to 23768. But that is perhaps unsurprising given that the
connection never gets to ASSURED.
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: DNAT working for one host but not another
2016-12-04 19:06 ` Brian J. Murrell
@ 2016-12-05 7:04 ` Llorente Santos Jesus
2016-12-05 14:43 ` Brian J. Murrell
0 siblings, 1 reply; 6+ messages in thread
From: Llorente Santos Jesus @ 2016-12-05 7:04 UTC (permalink / raw)
To: netfilter@vger.kernel.org
Hi Brian,
Did you try using the REDIRECT target instead?
Best,
Jesus
-----Original Message-----
From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of Brian J. Murrell
Sent: 04 December 2016 21:07
To: netfilter@vger.kernel.org
Subject: Re: DNAT working for one host but not another
On Sun, 2016-12-04 at 14:01 -0500, Brian J. Murrell wrote:
> I have a DNAT rule on a host who's purpose is to redirect traffic that
> is destined for port 23768 to port 5060 on that host:
I should add, that what is going back to the 10.75.23.212 host is also
wrong:
14:04:53.723018 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 0
14:04:53.877539 IP 10.75.22.8.5060 > 10.75.23.212.6060: SIP, length: 555
14:04:53.910351 IP 10.75.23.212.6060 > 10.75.22.8.23768: UDP, length 472
14:04:53.912158 IP 10.75.22.8.5060 > 10.75.23.212.6060: SIP, length: 555
As you can see, what is being returned is not having it's port un- natted back to 23768. But that is perhaps unsurprising given that the connection never gets to ASSURED.
Cheers,
b.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT working for one host but not another
2016-12-05 7:04 ` Llorente Santos Jesus
@ 2016-12-05 14:43 ` Brian J. Murrell
2016-12-05 15:52 ` Humberto Jucá
0 siblings, 1 reply; 6+ messages in thread
From: Brian J. Murrell @ 2016-12-05 14:43 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT working for one host but not another
2016-12-05 14:43 ` Brian J. Murrell
@ 2016-12-05 15:52 ` Humberto Jucá
2016-12-05 15:56 ` Brian J. Murrell
0 siblings, 1 reply; 6+ messages in thread
From: Humberto Jucá @ 2016-12-05 15:52 UTC (permalink / raw)
To: Brian J. Murrell, netfilter
What are the nf_nat modules running in memory?
lsmod | grep "nf_nat_"
To do this you can't load nf_nat_sip!
When I worked with siproxy, i had to remove this module from memory.
2016-12-05 11:43 GMT-03:00 Brian J. Murrell <brian@interlinx.bc.ca>:
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT working for one host but not another
2016-12-05 15:52 ` Humberto Jucá
@ 2016-12-05 15:56 ` Brian J. Murrell
0 siblings, 0 replies; 6+ messages in thread
From: Brian J. Murrell @ 2016-12-05 15:56 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
On Mon, 2016-12-05 at 12:52 -0300, Humberto Jucá wrote:
> What are the nf_nat modules running in memory?
>
> lsmod | grep "nf_nat_"
# lsmod | grep nf_nat
nf_nat_ipv6 14131 1 ip6table_nat
nf_nat_ipv4 14115 1 iptable_nat
nf_nat 26146 4 nf_nat_ipv4,nf_nat_ipv6,xt_nat,xt_REDIRECT
nf_conntrack 105737 7 nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,nf_conntrack_netlink,nf_conntrack_ipv4,nf_conntrack_ipv6
Kernel is 3.10.0
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-12-05 15:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-04 19:01 DNAT working for one host but not another Brian J. Murrell
2016-12-04 19:06 ` Brian J. Murrell
2016-12-05 7:04 ` Llorente Santos Jesus
2016-12-05 14:43 ` Brian J. Murrell
2016-12-05 15:52 ` Humberto Jucá
2016-12-05 15:56 ` Brian J. Murrell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox