Experimental Physics and Industrial Control System
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
>
- Replies:
- Re: Problem with the iptables DNAT filter Andrew Johnson
- References:
- Problem with the iptables DNAT filter Andrew Johnson
- Navigate by Date:
- Prev:
Problem with the iptables DNAT filter Andrew Johnson
- Next:
Jenkins build is back to normal : epics-base-3.16-win64 #104 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:
Problem with the iptables DNAT filter Andrew Johnson
- Next:
Re: Problem with the iptables DNAT filter Andrew Johnson
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024