EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Problem with the iptables DNAT filter
From: Andrew Johnson <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Mon, 8 May 2017 18:15:05 -0500
On 05/05/2017 06:41 PM, Michael Davidsaver wrote:
> My first reaction is that you have a good situation in which to test the
> as yet untested multicast name lookup feature added to CA.

Unfortunately I don't have much control over the Base version the CA
clients are running (and when I did experiment with using multicast
addresses some time back they didn't work for me; our network guy
doesn't have a particularly deep knowledge in this area, so I didn't
push it).

> I'm not surprised that the source port is being changed as I know in
> other situations (full NAT) that this is done, I believe, to make a
> unique entry in a mapping lookup table.
> 
> You might get some additional information from:
> 
> http://conntrack-tools.netfilter.org/conntrack.html

Useful tool, thanks — RHEL provides an RPM so I installed it, although
the documentation is somewhat lacking.

> See the '--dst-nat' filter.

Actually the --any-nat filter is more revealing:

> [root@tux sudo]# conntrack -E -p udp --any-nat
>     [NEW] udp      17 30 src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=5064 [UNREPLIED] src=164.54.11.255 dst=164.54.8.164 sport=5064 dport=58193
>     [NEW] udp      17 30 src=164.54.9.24 dst=164.54.8.164 sport=5064 dport=58193 [UNREPLIED] src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=1025
> [DESTROY] udp      17 src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=5064 [UNREPLIED] src=164.54.11.255 dst=164.54.8.164 sport=5064 dport=58193
> [DESTROY] udp      17 src=164.54.9.24 dst=164.54.8.164 sport=5064 dport=58193 [UNREPLIED] src=164.54.8.164 dst=164.54.9.24 sport=58193 dport=1025
> ^Cconntrack v1.4.3 (conntrack-tools): 4 flow events have been shown.

The second line there is it setting up the translation of the reply
source port number, which I want it to *not* do. Unfortunately after
lots of reading I get the impression that this isn't going to be
possible using the NAT mechanism; the kernel's Connection Tracking code
seems to have some mirroring functionality which requires some kind of
backwards translation to occur.


> You might get some mileage by modifying the rule to match when the
> source IP is on the local subnet by adding something like
> 
>> ! -s 192.168.1.0/24

Not sure how that might help, I still need the iptables rule to work for
clients from both local and remote subnets (local clients might be
configured with an explicit IP address in their ADDR_LIST instead of
using the broadcast address).


Looking at the netfilter.org documentation for NAT at
http://netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.3
I see this text, which I think explains what's going on:

> Implicit Source Port Mapping
> 
> Even when no NAT is requested for a connection, source port translation
> may occur implicitly, if another connection has been mapped over the
> new one. Consider the case of masquerading, which is rather common:
> 
> 1. A web connection is established by a box 192.1.1.1 from port 1024
>    to www.netscape.com port 80.
> 2. This is masqueraded by the masquerading box to use its source IP
>    address (1.2.3.4).
> 3. The masquerading box tries to make a web connection to
>    www.netscape.com port 80 from 1.2.3.4 (its external interface address)
>    port 1024.
> 4. The NAT code will alter the source port of the second connection to
>    1025, so that the two don't clash.

It's that last point which seems to be unalterable.

We developed a workaround, which was to run a PV Name Server on another
workstation in the same subnet as the IOC, configured for learning and
only searching for PVs from the IOC's IP address. We point our
firewalled clients to that nameserver, which points them to the IOC and
everything seems to work. Not ideal, but it's sufficient for now.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

References:
Problem with the iptables DNAT filter Andrew Johnson
Re: Problem with the iptables DNAT filter Michael Davidsaver

Navigate by Date:
Prev: Re: Build failed in Jenkins: epics-base-3.16-mac-test #97 Andrew Johnson
Next: Jenkins build is back to normal : epics-base-3.16-mac-test #98 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Problem with the iptables DNAT filter Michael Davidsaver
Next: Build failed in Jenkins: epics-base-3.16-win64-test #59 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·