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
<2017>
2018
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
<2017>
2018
2019
2020
2021
2022
2023
2024
|