>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
[email protected]
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
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.
-A INPUT -s 192.168.0.0/22 -p
udp --sport 5064 -j ACCEPT
takes
care of incoming responses to PV search requests.
-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.