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
--
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
- Replies:
- Re: Problem with the iptables DNAT filter Michael Davidsaver
- Navigate by Date:
- Prev:
Build failed in Jenkins: epics-base-3.16-win32s-test #70 APS Jenkins
- Next:
Re: Problem with the iptables DNAT filter Michael Davidsaver
- 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: windows build/test failures Andrew Johnson
- Next:
Re: Problem with the iptables DNAT filter Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|