Re: Traffic redirect no longer working
i think it's simpler if you write this as one rule: pass in quick on $ext_if proto tcp from $work_hosts to $ssh_host \ port ssh rdr-to $ssh_host modulate state is there any change if you remove 'modulate state'? do you have any other 'match' rules that would apply to these packets? reduce the ruleset to the minimum needed for the redirection and anything critical; if it still shows the problem then it would be useful to post the ruleset. On 2010-05-25, Lars Hecking lheck...@users.sourceforge.net wrote: lheck...@users.sourceforge.net writes: I've used the same pf.conf for years with only minimal changes, but 4.7 broke it, and I can't seem to fix it. The OBSD machine is a firwall between a cable modem and a private IP LAN. Previously, I used these rules to allow ssh access from specific Internet hosts to a machine in the LAN: rdr on $ext_if proto tcp from $work_hosts to any port ssh - $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state In 4.7, I changed this to match in on $ext_if proto tcp from $work_hosts to any port ssh rdr-to $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state What happens now when I try to connect to $ssh_host from the Internet is quite weird: - no blocked packets are logged - on the firewall's LAN-side interface, a tcpdump shows the ssh connection being forwarded to $ssh_host - on $ssh_host, tcpdump shows the incoming ssh connection - sshd on $ssh_host does not pick up I can ssh from the firewall to $ssh_host just fine; I haven't tested ssh from Internet to firewall (with suitable pass rule). What am I missing? I guess that some packet information isn't being rewritten correctly or completely. I still haven't gotten any further. Thanks to Scott, Neal, and Peter's BSDCan slides, I have rewritten chunks of pf.conf so that it's fully up to date wrt 4.7. The subject of my post is actually incorrect because the redirect is working, which I can verify with tcpdumps of the gateway external and internal interface, pflog, and tcpdump on the target host's interface. Looking at the tcpdumps in wireshark, I only see one-way traffic on the ssh port, i.e. only SYN, but no ACK. It doesn't matter whether the target is e.g a Linux or FreeBSD host. Any idea why this would be happening? I can ssh from the outside to the gw (with suitable pass rules), and from the gw to the internal host. All these observations taken together make it look like pf is mucking up the packets in transit. I'm stumped. All other aspects of the pf config appear to work fine. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Re: Traffic redirect no longer working
Stuart Henderson writes: i think it's simpler if you write this as one rule: pass in quick on $ext_if proto tcp from $work_hosts to $ssh_host \ port ssh rdr-to $ssh_host modulate state I've done that after looking at Peter's presentation :) is there any change if you remove 'modulate state'? I don't think I'm using that in my current config, but will check later. do you have any other 'match' rules that would apply to these packets? Potentially yes, but pflog shows the packets are matched by the correct rules. Will confirm later when I'm home. reduce the ruleset to the minimum needed for the redirection and anything critical; if it still shows the problem then it would be useful to post the ruleset. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Re: Traffic redirect no longer working
Stuart Henderson writes: i think it's simpler if you write this as one rule: pass in quick on $ext_if proto tcp from $work_hosts to $ssh_host \ port ssh rdr-to $ssh_host modulate state Not quite, since $ssh_host is on the private IP network This is the rule pass in log quick on $ext_if inet proto tcp from $work_hosts to ($ext_if) \ port ssh rdr-to $ssh_host $tcp_flags tag ext_ssh is there any change if you remove 'modulate state'? Nope. do you have any other 'match' rules that would apply to these packets? The redirection works, as this log shows. vr0=ext_if, vr1=int_if, I've replaced the name of the connectiong host with $work_hosts, the IP of the ssh_host with $ssh_host, and the IP of my gateway with GWIP. May 25 21:40:41.598026 rule 24/(match) pass in on vr0: $work_hosts.6935 GWIP.ssh: S 2571626156:2571626156(0) win 5840 mss 1380,sackOK,timestamp 556768519[|tcp] (DF) [tos 0x60] May 25 21:40:41.598137 rule 26/(match) pass out on vr1: $work_hosts.6935 $ssh_host.ssh: S 2973802996:2973802996(0) win 5840 mss 1380,sackOK,timestamp 556768519[|tcp] [tos 0x60] reduce the ruleset to the minimum needed for the redirection and anything critical; if it still shows the problem then it would be useful to post the ruleset. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Re: Traffic redirect no longer working
lheck...@users.sourceforge.net writes: I've used the same pf.conf for years with only minimal changes, but 4.7 broke it, and I can't seem to fix it. The OBSD machine is a firwall between a cable modem and a private IP LAN. Previously, I used these rules to allow ssh access from specific Internet hosts to a machine in the LAN: rdr on $ext_if proto tcp from $work_hosts to any port ssh - $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state In 4.7, I changed this to match in on $ext_if proto tcp from $work_hosts to any port ssh rdr-to $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state What happens now when I try to connect to $ssh_host from the Internet is quite weird: - no blocked packets are logged - on the firewall's LAN-side interface, a tcpdump shows the ssh connection being forwarded to $ssh_host - on $ssh_host, tcpdump shows the incoming ssh connection - sshd on $ssh_host does not pick up I can ssh from the firewall to $ssh_host just fine; I haven't tested ssh from Internet to firewall (with suitable pass rule). What am I missing? I guess that some packet information isn't being rewritten correctly or completely. I still haven't gotten any further. Thanks to Scott, Neal, and Peter's BSDCan slides, I have rewritten chunks of pf.conf so that it's fully up to date wrt 4.7. The subject of my post is actually incorrect because the redirect is working, which I can verify with tcpdumps of the gateway external and internal interface, pflog, and tcpdump on the target host's interface. Looking at the tcpdumps in wireshark, I only see one-way traffic on the ssh port, i.e. only SYN, but no ACK. It doesn't matter whether the target is e.g a Linux or FreeBSD host. Any idea why this would be happening? I can ssh from the outside to the gw (with suitable pass rules), and from the gw to the internal host. All these observations taken together make it look like pf is mucking up the packets in transit. I'm stumped. All other aspects of the pf config appear to work fine. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Traffic redirect no longer working
I've used the same pf.conf for years with only minimal changes, but 4.7 broke it, and I can't seem to fix it. The OBSD machine is a firwall between a cable modem and a private IP LAN. Previously, I used these rules to allow ssh access from specific Internet hosts to a machine in the LAN: rdr on $ext_if proto tcp from $work_hosts to any port ssh - $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state In 4.7, I changed this to match in on $ext_if proto tcp from $work_hosts to any port ssh rdr-to $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state What happens now when I try to connect to $ssh_host from the Internet is quite weird: - no blocked packets are logged - on the firewall's LAN-side interface, a tcpdump shows the ssh connection being forwarded to $ssh_host - on $ssh_host, tcpdump shows the incoming ssh connection - sshd on $ssh_host does not pick up I can ssh from the firewall to $ssh_host just fine; I haven't tested ssh from Internet to firewall (with suitable pass rule). What am I missing? I guess that some packet information isn't being rewritten correctly or completely. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Re: Traffic redirect no longer working
On 05/21/10 05:37, lheck...@users.sourceforge.net wrote: rdr on $ext_if proto tcp from $work_hosts to any port ssh - $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state In 4.7, I changed this to match in on $ext_if proto tcp from $work_hosts to any port ssh rdr-to $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state [...] I can ssh from the firewall to $ssh_host just fine; I haven't tested ssh from Internet to firewall (with suitable pass rule). What am I missing? I guess that some packet information isn't being rewritten correctly or completely. Without knowing your details, I'm going to guess you need a pass out rule for your internal interface. Give it a try. I use this: pass out quick on $int1_if tagged ext_ssh but I also tag the matching incoming traffic. -- - RSM www.erratic.ca
Re: Traffic redirect no longer working
On Fri, May 21, 2010 at 4:37 AM, lheck...@users.sourceforge.net wrote: I've used the same pf.conf for years with only minimal changes, but 4.7 broke it, and I can't seem to fix it. Reconsider the PF documentation. There have been some changes to the syntax in 4.7. The OBSD machine is a firwall between a cable modem and a private IP LAN. Previously, I used these rules to allow ssh access from specific Internet hosts to a machine in the LAN: rdr on $ext_if proto tcp from $work_hosts to any port ssh - $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state In 4.7, I changed this to match in on $ext_if proto tcp from $work_hosts to any port ssh rdr-to $ssh_host pass in quick on $ext_if proto tcp \ from $work_hosts to $ssh_host port ssh flags S/SA modulate state What happens now when I try to connect to $ssh_host from the Internet is quite weird: - no blocked packets are logged - on the firewall's LAN-side interface, a tcpdump shows the ssh connection being forwarded to $ssh_host - on $ssh_host, tcpdump shows the incoming ssh connection - sshd on $ssh_host does not pick up I can ssh from the firewall to $ssh_host just fine; I haven't tested ssh from Internet to firewall (with suitable pass rule). What am I missing? I guess that some packet information isn't being rewritten correctly or completely. --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
Re: Traffic redirect no longer working
On Fri, May 21, 2010 at 6:39 AM, Lars Hecking lheck...@users.sourceforge.net wrote: Neal Hogan writes: On Fri, May 21, 2010 at 4:37 AM, lheck...@users.sourceforge.net wrote: ?I've used the same pf.conf for years with only minimal changes, but 4.7 ?broke it, and I can't seem to fix it. Reconsider the PF documentation. There have been some changes to the syntax in 4.7. Been over that. The documentation isn't quite up to date (e.g. the examples section in the pf FAQ), and my rules are syntactically correct. Just to be exhaustive: http://marc.info/?l=openbsd-miscm=125181847818600w=2 But a nice person from Canada has given me a few suggestions I'm going to try later. Thanks, Lars --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. ---
