Re: VPN client cannot connect through OpenBSD router/firewall
On Mon, Jan 17, 2005 at 02:48:07PM -0600, Rick Barter wrote: Michael Erdely wrote: You're doing a block all and then aren't allowing esp traffic out. Try adding the following with your tcp, udp and icmp pass out rules: pass out $log_flg on $ext_if proto esp all keep state When troubleshooting something like this, it may be useful to to add log to your default block rule so you'll at least see what's being dropped. Thank you very much for the advice. This worked like a charm. How did you know, or better yet, how could I have known that I needed to pass out the esp protocol? By seeing what was dropped? yup. by seeing what was dropped. i _always always always_ keep block return log all as the first real rule in my pf.conf. whether or not you want to return or drop is of course a matter of taste ( i do drop some things later in a more specific rule ), and whether or not you want to block all ifaces or not is a matter of taste too... for annoying things like crackwhores trying to hit my TCP:135 pipe and the like, i create specific non-log block rules for them so my pflog0 and /var/log/pflog actually contain useful data when i look at them. just as long as you avoid the bitch-out temptation of setting some 'pass quick all' rule right after that, you'll be on the quick way to solving things for yourself. as a sidebar, i succumbed to that very same bitch-out temptation just a bit ago and was completely confused why my pf was NOT blocking incoming UDP:500 from a friend of mine after he changed ISPs and thus had an IP which was not in my pf table of allowed VPN Gateways. my pass quick all log was shooting my entire rule logic in the face (stupid!). i won't claim to be captain pants of setting up pf in all cases, however i have no difficulty recalling many instances over the years of someone asking a question to pf@ which they would *not* have had to ask had they been logging their blocks ( eg - they come back 2w later and say oh, i'm dumbass, i was blocking that but didn't know ). log your blocks for chrissake all the time :P jared -- [ openbsd 3.6 GENERIC ( dec 11 ) // i386 ]
Re: VPN client cannot connect through OpenBSD router/firewall
jared r r spiegel wrote: yup. by seeing what was dropped. i _always always always_ keep block return log all as the first real rule in my pf.conf. whether or not you want to return or drop is of course a matter of taste ( i do drop some things later in a more specific rule ), and whether or not you want to block all ifaces or not is a matter of taste too... Okay. So I have the following (not the whole pf.conf file): #= # Macros #= log_flg = log #= # Options #= set block-policy drop set loginterface $ext_if #= # Filter Rules #= block $log_flg all pass $log_flg quick on lo0 all antispoof $log_flg quick for $ext_if antispoof $log_flg quick for $dmz_if antispoof $log_flg quick for $int_if block drop in $log_flg quick on $ext_if from $priv_nets to any block drop out $log_flg quick on $ext_if from any to $priv_nets Why would I not see the dropped packets in my log file (pflog0). Should I be setting pflog0 as my loginterface instead of fxp0? rvb
Re: VPN client cannot connect through OpenBSD router/firewall
On Mon, 17 Jan 2005 22:38:05 +0100, Laurent Cheylus [EMAIL PROTECTED] wrote: Hi Rick, On Mon, Jan 17, 2005 at 12:06:54PM -0600, Rick Barter wrote: Okay. I have a problem that I can't get my brain around and I need some help. My wife needs to connect to her VPN at work. I've captured packets for her connection and see that it's connecting to her work server on ports 53 (dns) and 500 (isakmp). Are you sure about the port 53 part? Normally UDP/53 would be used once to find the IP address of the VPN gateway, then the connection is negotiated using IKE on UDP/500 (both source and destination port are 500) then the actually VPN traffic continues on IP Protocol 50 (ESP). The client may later do further handshaking on UDP/500 for rekey, etc. Many headends enforce the requirement that incoming IKE packets have both source and destination port of 500. PAT will rewrite the source port, causing the IKE packets from the internal client to be rejected at the headend. I thought that since she was initiating the connections to port 53 and 500 that the keep state entries on the outbound tcp and udp traffic would be enough to ensure she could connect and wouldn't require me to set up NAT for these connections. Am I wrong? What am I missing here? Correct. There should not be a need for adding specific NAT policies just for the VPN. The existing NAT and keep state should suffice. According to your pf.conf, your TCP/UDP outbond connections are nated. To use VPN IPsec client with a NAT gateway like yours, VPN client must use NAT-Traversal (ESP packets encapsulation in UDP packets on port 4500). And the IPsec gateway of your wife at work must also support NAT-Traversal. Nat-Traversal is not absolutely required for a VPN session using ESP in Tunnel Mode to succeed through a smart (static-port, IPSEC-aware) NAT. The core of the problem is that NAT breaks AH, will break ESP in transport mode, and PAT can cause problems with IKE.
Re: VPN client cannot connect through OpenBSD router/firewall
Rick Barter wrote:
Okay. I have a problem that I can't get my brain around and I need some
help. My wife needs to connect to her VPN at work. I've captured
packets for her connection and see that it's connecting to her work
server on ports 53 (dns) and 500 (isakmp).
I have been doing a lot of reading (Artymiak, OpenBSD PF Manual) and
searching (Google and Archives), but I'm still not understanding
something I guess.
I thought that since she was initiating the connections to port 53 and
500 that the keep state entries on the outbound tcp and udp traffic
would be enough to ensure she could connect and wouldn't require me to
set up NAT for these connections. Am I wrong? What am I missing here?
Thank you for any help. My pf.conf is below.
rvb
#=
# Macros
#=
log_flg = # log for on and for off
ext_if = fxp0
dmz_if = xl0
int_if = xl1
dmz_ip = 192.168.2.199
win_ip = 192.168.3.100
#=
# Port Nbr Mapping
#=
ssh = 22
ident = 113
irc_dcc = 1024:1066
web_svr = 80
tomcat = 8080
tcp_services = { $ssh }
icmp_types = echoreq
priv_nets = { 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8
}
#=
# Options
#=
set block-policy drop
set loginterface $ext_if
#=
# Scrub Rules
#=
scrub in all
#=
# NAT and Forwarding Rules
#=
nat on $ext_if from $int_if:network to any - ($ext_if)
nat on $ext_if from $dmz_if:network to any - ($ext_if)
prefix_ext = rdr on $ext_if proto tcp from any to $ext_if port
$prefix_ext $web_svr - $dmz_ip
$prefix_ext $tomcat - $dmz_ip
$prefix_ext $ident - $win_ip
$prefix_ext $irc_dcc - $win_ip
# lan traffic to web server
rdr on $int_if proto tcp from any to $ext_if port $web_svr - $dmz_ip
# lan traffic to servlet engine
rdr on $int_if proto tcp from any to $ext_if port $tomcat - $dmz_ip
#=
# Filter Rules
#=
block all
pass $log_flg quick on lo0 all
antispoof $log_flg quick for $ext_if
antispoof $log_flg quick for $dmz_if
antispoof $log_flg quick for $int_if
block drop in $log_flg quick on $ext_if from $priv_nets to any
block drop out $log_flg quick on $ext_if from any to $priv_nets
# tcp_services
pass in $log_flg on $ext_if inet proto tcp from any to ($ext_if) \
port $tcp_services flags S/SA keep state
# web server
pass in $log_flg on $ext_if proto tcp from any to $dmz_ip port $web_svr \
flags S/SA synproxy state
# servlet/jsp engine
pass in $log_flg on $ext_if proto tcp from any to $dmz_ip port $tomcat \
flags S/SA synproxy state
# ident requests
pass in $log_flg on $ext_if proto tcp from any to $win_ip port $ident
# dcc send
pass in $log_flg on $ext_if proto tcp from any to $win_ip port $irc_dcc
# ping requests
pass in $log_flg inet proto icmp all icmp-type $icmp_types keep state
# pass out all tcp, udp, and icmp packets
pass out $log_flg on $ext_if proto tcp all modulate state flags S/SA
pass out $log_flg on $ext_if proto { udp, icmp } all keep state
# pass all traffic to the dmz
pass in $log_flg on $dmz_if from $dmz_if:network to any keep state
pass out $log_flg on $dmz_if from any to $dmz_if:network keep state
# pass all traffic to and from the local network
pass in $log_flg on $int_if from $int_if:network to any keep state
pass out $log_flg on $int_if from any to $int_if:network keep state
It seems that you forgot about enc0 (in fact you are blocking it by
using 'block all'). Use 'man vpn' to see an example.
--
Insanity in individuals is something rare - but in groups, parties,
nations and epochs, it is the rule.
Re: VPN client cannot connect through OpenBSD router/firewall
On Mon, Jan 17, 2005 at 10:38:05PM +0100, the unit calling itself Laurent Cheylus wrote: Okay. I have a problem that I can't get my brain around and I need some help. My wife needs to connect to her VPN at work. I've captured packets for her connection and see that it's connecting to her work server on ports 53 (dns) and 500 (isakmp). [...] I thought that since she was initiating the connections to port 53 and 500 that the keep state entries on the outbound tcp and udp traffic would be enough to ensure she could connect and wouldn't require me to set up NAT for these connections. Am I wrong? What am I missing here? According to your pf.conf, your TCP/UDP outbond connections are nated. To use VPN IPsec client with a NAT gateway like yours, VPN client must use NAT-Traversal (ESP packets encapsulation in UDP packets on port 4500). And the IPsec gateway of your wife at work must also support NAT-Traversal. What is the IPsec client used by your wife and the IPsec gateway implementation used at her work ? SSH Sentinel and Safenet SoftRemote are commercial VPN clients that supports NAT-Traversal. isakmpd supports also NAT-Traversal since OpenBSD version 3.6 :-) I have the same problem. My VPN client is Cisco VPN Client ver 4.6.00. I gather that pf can't pass some VPN traffic, and that getting it through pf will require some isakmpd setup? Thanks, Jay
