Re: firewalld configuration for EPICS?

[Dirk Zimoch via Tech-talk <tech-talk@aps.anl.gov>]

I had not thought of the multiple IOC problem. In this case it is a 
Fedora Linux VME IOC. Unlikely to run multiple IOCs but not impossible.

I tried it and naively accessing records on IOC 2 does not work when the 
firewall is up. I get  'CAC: Unable to connect because "No route to 
host"' on the client (caget) even when using the broadcast address.

The iptables solution described on 
https://wiki-ext.aps.anl.gov/epics/index.php does not even apply in this 
case because I did not use unicast.

The firewall would need to allow the dynamically assigned TCP port of 
the second IOC. Unfortunately the second IOC only prints the port on the 
screen but it is not available e.g. in an environment variable. If so 
this would allow to execute a program (e.g. iptables or firewall-cmd) to 
open the port. (Closing it when the IOC dies unexpectedly is far more 
difficult. One would have to monitor the process externally.)

There is nothing built into firewalld to work on executables instead of 
port numbers (i.e. allow all ports opened by softIoc), is it?

Another solution would be to run a channel access gateway on the host as 
the one and only access point from the outside world (using port 5064) 
and broadcast on localhost to the IOCs. I am not sure about the 
performance implications though.

I think I rather disable the firewall for the time being.

Thanks for your replies.
Dirk


On 08.04.19 17:28, Benjamin Franksen via Tech-talk wrote:
> Am 05.04.19 um 14:28 schrieb Dirk Zimoch via Tech-talk:
> > I Installed it (without ca-2/tcp) and it work fine.
>
> We found that such firewall rules do not work well in combination with
> multiple soft IOCs on Linux. The problem is that for multiple CA servers
> on the same machine to work as expected, it is necessary to add certain
> iptables rules (see
> https://wiki-ext.aps.anl.gov/epics/index.php/How_to_Make_Channel_Access_Reach_Multiple_Soft_IOCs_on_a_Linux_Host)
> that convert incoming UDP unicasts (name resolution requests) to
> broadcasts, internally. Unicasts will be sent when the client sets
> EPICS_CA_ADDR_LIST to request a specific server.
>
> The iptables solution is quite elegant but has an unfortunate
> side-effect: the source port of the response packets will be re-written
> to some randomly chosen ephemeral port. And that port doesn't match the
> ports configured for the firewall, so the firewall doesn't let them
> through. It is hard to find documentation for this behavior of iptables
> on the internet. The keyword here is "implicit source port mapping".
>
> We have been thinking about this problem for a while. I think the only
> clean solution is for EPICS to offer something similar to the already
> existing caRepeater, only for the server side. Let me call this thing
> the "casRepeater". Similar to the CA client with the caRepeater, each CA
> server would on startup try to locate a running instance of the
> casRepeater, or else start a new one, then register with it. The task of
> the casRepeater is to listen on port 5065 for unicasts and then forward
> them to all registered CA servers.
>
> Cheers
> Ben