RE: Firewall (iptables) issues?

["Jeff Hill" <johill@lanl.gov>]

>I don't understand.  The rules that I presented are for inbound packets.

>If you want channel access _clients_ on a machine to be able to see _replies_ to broadcast PV search requests

 

> The first rule

>          -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT

> takes care of incoming responses to PV search requests.

 

The server typically does not send udp response frames back to the client using port 5064

as the destination address because the client’s udp port is ephemeral (dynamically assigned).

The server instead sends it responses to a destination address which is whatever source

address it finds in the incoming udp request frame.

 

Thus enabling 5064 for the client doesn’t hurt anything, but it probably doesn’t help, actually

emasculates the firewall, and maybe it works now for you only because the stateful firewall transparently

allows replies from the server that are being sent to the client’s ephemeral port. The stateful

firewall can actually remember the source address for the search requests and briefly allow

replies sent to that same destination.

 

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

 

Message content: TSPA

 

With sufficient thrust, pigs fly just fine. However, this is

not necessarily a good idea. It is hard to be sure where they

are going to land, and it could be dangerous sitting under them

as they fly overhead. -- RFC 1925

 

From: Eric Norum [mailto:wenorum@lbl.gov]
Sent: Friday, November 05, 2010 4:25 PM
To: Jeff Hill
Cc: tech-talk@aps.anl.gov
Subject: Re: Firewall (iptables) issues?

 

I don't understand.  The rules that I presented are for inbound packets.   I explicitly noted that they are sufficient only under the assumption that outbound packets are not filtered.

 

The first rule

          -A INPUT -s 192.168.0.0/22 -p udp --sport 5064 -j ACCEPT

takes care of incoming responses to PV search requests.

 

The second rule

          -A INPUT -s 192.168.0.0/22 -p udp --dport 5065 -j ACCEPT

takes care of incoming beacons.

 

As far as I can tell, and as far as my empirical tests showed, these are sufficient to allow clients to operate on a firewalled machine.

 

Could you clarify as to what you feel I've missed?

 

On Nov 5, 2010, at 3:14 PM, Jeff Hill wrote:

Hi Eric,

If you want channel access clients on a machine to be able to see

replies to broadcast PV search requests you need to permit inbound

UDP packets with source port EPICS_CA_SERVER_PORT (default is 5064)

The server always replies sending to the source address found in the udp
frame containing the client's search request. Since the client library's
UDP socket is locally bound to an ephemeral (dynamically assigned) port
number, and that will be its source address when sending udp search frames,
then it's probably not strictly accurate to say that the firewall can permit
these responses by opening up port EPICS_CA_SERVER_PORT (default is 5064).

I seem to recall that certain stateful firewall implementations remember
the source address of outbound udp frames and, for some amount of time
afterwards, transparently permit udp replies returning to that same
address.

 

-- 
Eric Norum
wenorum@lbl.gov