Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Fri, 5 May 2017 19:41:43 -0400

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.

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

See the '--dst-nat' filter.

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

On 05/05/2017 07:01 PM, Andrew Johnson wrote:
> We have a Linux host running several soft IOCs with Ralph's iptables
> network filter as described at
> 
> https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_on_a_Linux_Host
> 
> This works fine for most CA clients, but we have one client which is the
> other side of (actually inside) a firewall which is unable to access PVs
> on any of those IOCs. It has no problem connecting to IOCs on
> workstations that do *not* have the iptables rule installed.
> 
> I duplicated the issue on my workstation and ran wireshark to see the
> differences, and it seems that the filter is changing the source port
> number of the reply UDP message. Here is the reply with no filter:
> 
>> No.     Time               Source                Destination           Protocol Length Info
>>       8 15:22:40.582099303 164.54.9.24           164.54.2.28           UDP      82     Source port: ca-1  Destination port: 57897
>>
>> Frame 8: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0
>> Ethernet II, Src: HewlettP_2f:fd:7e (6c:3b:e5:2f:fd:7e), Dst: Cisco_9f:f0:08 (00:00:0c:9f:f0:08)
>> Internet Protocol Version 4, Src: 164.54.9.24 (164.54.9.24), Dst: 164.54.2.28 (164.54.2.28)
>> User Datagram Protocol, Src Port: ca-1 (5064), Dst Port: 57897 (57897)
>>     Source port: ca-1 (5064)
>>     Destination port: 57897 (57897)
>>     Length: 48
>>     Checksum: 0x53e2 [validation disabled]
>> Data (40 bytes)
>>
>> 0000  00 00 0c 9f f0 08 6c 3b e5 2f fd 7e 08 00 45 00   ......l;./.~..E.
>> 0010  00 44 7e a1 40 00 40 11 68 67 a4 36 09 18 a4 36   .D~.@[email protected]
>> 0020  02 1c 13 c8 e2 29 00 30 53 e2 00 00 00 00 00 01   .....).0S.......
>> 0030  00 0d 00 00 00 01 00 00 00 00 00 06 00 08 13 c8   ................
>> 0040  00 00 ff ff ff ff 00 00 00 01 00 0d 00 00 00 00   ................
>> 0050  00 00                                             ..
> 
> Here is the same reply with the filter installed:
> 
>> No.     Time               Source                Destination           Protocol Length Info
>>       8 15:15:43.621132017 164.54.9.24           164.54.2.28           UDP      82     Source port: blackjack  Destination port: 57313
>>
>> Frame 8: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0
>> Ethernet II, Src: HewlettP_2f:fd:7e (6c:3b:e5:2f:fd:7e), Dst: Cisco_9f:f0:08 (00:00:0c:9f:f0:08)
>> Internet Protocol Version 4, Src: 164.54.9.24 (164.54.9.24), Dst: 164.54.2.28 (164.54.2.28)
>> User Datagram Protocol, Src Port: blackjack (1025), Dst Port: 57313 (57313)
>>     Source port: blackjack (1025)
>>     Destination port: 57313 (57313)
>>     Length: 48
>>     Checksum: 0x53e2 [validation disabled]
>> Data (40 bytes)
>>
>> 0000  00 00 0c 9f f0 08 6c 3b e5 2f fd 7e 08 00 45 00   ......l;./.~..E.
>> 0010  00 44 65 1d 40 00 40 11 81 eb a4 36 09 18 a4 36   .De.@[email protected]
>> 0020  02 1c 04 01 df e1 00 30 53 e2 00 00 00 00 00 01   .......0S.......
>> 0030  00 0d 00 00 00 01 00 00 00 00 00 06 00 08 13 c8   ................
>> 0040  00 00 ff ff ff ff 00 00 00 01 00 0d 00 00 00 00   ................
>> 0050  00 00                                             ..
> 
> The source port number in the packet no longer marks this as CA traffic,
> so our firewall won't let it pass through.
> 
> Anybody got any ideas how to fix this? Would the DNAT do that itself if
> we added the filter to the OUTPUT chain as well? The manpage for DNAT
> says "It specifies that the destination address of the packet should be
> modified (and all future packets in this connection will also be
> mangled)". I have no idea how to do that...
> 
> - Andrew
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System