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
> 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:
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=220.127.116.11 dst=18.104.22.168 sport=58193 dport=5064 [UNREPLIED] src=22.214.171.124 dst=126.96.36.199 sport=5064 dport=58193
> [NEW] udp 17 30 src=188.8.131.52 dst=184.108.40.206 sport=5064 dport=58193 [UNREPLIED] src=220.127.116.11 dst=18.104.22.168 sport=58193 dport=1025
> [DESTROY] udp 17 src=22.214.171.124 dst=126.96.36.199 sport=58193 dport=5064 [UNREPLIED] src=188.8.131.52 dst=184.108.40.206 sport=5064 dport=58193
> [DESTROY] udp 17 src=220.127.116.11 dst=18.104.22.168 sport=5064 dport=58193 [UNREPLIED] src=22.214.171.124 dst=126.96.36.199 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
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 188.8.131.52 from port 1024
> to www.netscape.com port 80.
> 2. This is masqueraded by the masquerading box to use its source IP
> address (184.108.40.206).
> 3. The masquerading box tries to make a web connection to
> www.netscape.com port 80 from 220.127.116.11 (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.
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
- Problem with the iptables DNAT filter Andrew Johnson
- Re: Problem with the iptables DNAT filter Michael Davidsaver
- Navigate by Date:
Re: Build failed in Jenkins: epics-base-3.16-mac-test #97 Andrew Johnson
Jenkins build is back to normal : epics-base-3.16-mac-test #98 APS Jenkins
- Navigate by Thread:
Re: Problem with the iptables DNAT filter Michael Davidsaver
Build failed in Jenkins: epics-base-3.16-win64-test #59 APS Jenkins