Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: Problem with the iptables DNAT filter
From: Andrew Johnson <anj@aps.anl.gov>
To: EPICS core-talk <core-talk@aps.anl.gov>
Date: Fri, 5 May 2017 18:01:19 -0500
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~.@.@.hg.6...6
> 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.@.@....6...6
> 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
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
ANJ, 08 May 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·