Vpn client through Pf firewall

Submitted by Anonymous
on April 20, 2004 - 1:02am

i had setup pf firewall using OpenBSD 3.4. One of the win2k machine in our lan installed netscreen vpn client. when is try to login to the vpn server located in our client place, its able to login. After that when i tried to login to the remote server through vps connection, its saying no such machines are available. Help me to solve this issue

Thanks in advance

Raju

I have the exact same problem

Anonymous
on
April 20, 2004 - 6:27pm

I have the exact same problem. Whatever I do I am unable to get a Cisco software VPN client to connect to my companys VPN through an OpenBSD firewall, and believe me, I've tried googling for it, I tried asking people who work with this stuff, all to no avail.

I'm not sure what goes on, but it seems like the pf believes every VPN package is meant for the OpenBSD machine (or something sitting on the OpenBSD box as default puts the package into a deep black dark hole). The outbound connection works just fine, but pf doesn't connect the dots when the VPN server answers back and thus disallows packages from the server... wonderful firewall this pf/OpenBSD thing....

At home using NAT/Iptables I have no problems whatsoever. I even have a sucky dual nat setup due to my adsl "Cisco" 677 router, and still no problems at all.

I've given up on this issue, don't use an OpenBSD firewall if you want VPN passthrough!

OHM

Works fine for me.

Anonymous
on
April 20, 2004 - 6:50pm

I use the Cisco VPN client in a Windows XP VMware image on my Linux box at home to connect through an OpenBSD 3.4 firewall to our company's VPN. I've never had a single problem with it. In fact, it worked without any special tweaking of the client or the firewall.

Vpn client through iptables to remote vpn server

on
June 16, 2005 - 9:20am

I'd like to know how you did your iptables script to allow vpn traffic through. I have to allow one of my LAN clients behind my iptables to remote connect to a VPN server. When setting the firewall only as a router, the vpn client is able to connect to the remote vpn server. But when I put back my iptables script, the client can't connect anymore.

Honestly, I'm quite new to iptables scripting, but daily services are served well through my script and the LAN is well secured. But this vpn stuff drives me crazy, and I don't find any tutorial explaining carefully what to do to set up vpn traffic through iptables.

Looks like you did it seamlessly, may be you could give me some tips.

Thanks in advance.

Al

Suggestion: Use LOG-target

LennieNotLoggedIn (not verified)
on
February 6, 2008 - 10:06pm

Use the LOG-target or the iptables -nvL option to find out which rule is the one blocking your traffic.

Use the TRACE target to get

Anonymous (not verified)
on
June 1, 2008 - 8:19am

Use the TRACE target to get detailed information.

You really need to post your

Anonymous
on
May 2, 2004 - 1:12pm

You really need to post your pf.conf so that others can help.

It has to be set up to comply to particular RFCs

on
May 2, 2004 - 3:21pm

NAT involves changing headers. However, IPSec involves signing them. There has been a workaround for the workaround published - of course. :)

Basically, on the remote and local box you'll need to enable something like "NAT Traversal" as documented Here.

Oh, and you'll need to have a NAT compliant with the provisions of RFC 3715 (This is also an informational RFC, describing the natural incompatibilities between NAT and IPSec).

HTH

The vandy monster

VPN client

Anonymous
on
May 15, 2004 - 9:41am

The only one I have found so far that has been able to see the internal network is the VPN client offered by thegreenbow.com. The only problem is that it does NOT see the PDC / wins traffic (yet).

So, you'll have to setup SMB for network shares.

Best,

Phillip B. Holmes

You *can* do it with OpenBSD/pf

Anonymous
on
September 21, 2004 - 1:32am

What you need to do for VPN to work is use a "NAT Proxy", as it says in the man pages for pf.conf. Here is the line in my pf.conf that takes care of it:
nat on $ext_if inet proto { tcp, udp } from $internal port = 500 to any -> ($ext_if:0) port 500

Of course, you still need your general NAT rule in addition to this. But what this tells pf to do is NAT your traffic to the public IP *but* keep the source port = 500. You need this because ISAKMP must go from port 500 to port 500 - no way around it. So, if your firewall translates to some random high port on the way out, it will fail to establish a session with the VPN switch. Got it? Sweet.

Not entirely true...

Anonymous
on
October 11, 2004 - 12:38pm

I don't have any such rules in my pf.conf and I can use the Cisco VPN client to connect to our corporate VPN 3000 concentrator.

I haven't looked at the Cisco VPN server config but I figure it's handling IPSec/NAT traversal as outlined in various places. Anyhow it appears to be a function of the terminating VPN point rather than the client; if your VPN termination doesn't support IPSec/NAT traversal then your statement probably applies.

It does not work for me

André (not verified)
on
April 8, 2005 - 4:58am

The client is a Windows XP PRO using Netscreen-remote in tunneling mode.
Our firewall is an OpenBSD 3.4 performing NAT.
The settings of the Netscreen-remote client are OK since I can connect from home
(where I also use NAT with my Linksys router with IPSEC passthru)

The connection to the VPN server seems successfull (see netscreen-remote log below)
but I can't access the a remote machine, even though packets seems to pass the firewall
(as observed by tcpdump on $ext_if and $int_if).

The exact configuration of netscreen-remote is :
-)connect using Secure gateway tunnel
-)gataway address is 123.123.123.123 (exact address replaced)
-)remote party is single ip address 10.153.8.10 all protocols allowed
-)phase 1 negotiation is "Aggressive Mode"
-)Perfect Forward Secrecy enabled (Diffie-Hellman Group 2)
-)replay detection enabled
-)authentication: pre-shared key, encription triple DES, hash SHA-1,
encapsulation ESP tunnel

pf settings are (relevant lines):

scrub in all
#tried the following line but it did not help...
#binat pass on $ext_if from $internal_laptop to $vpn_server -> $ext_if
nat on $ext_if inet proto {tcp, udp} from $int_lan port = 500 to any \
-> ($ext_if) port 500
nat on $ext_if from { $int_lan } to any -> ($ext_if)
block in log on $ext_if all
pass in log proto esp from any to $int_lan # may be to widely open?

Netscreen-remote log (vpn server address replaced by 123.123.123.123):
4-08: 10:28:12.533 My Connections\cediti - Initiating IKE Phase 1 (IP ADDR=123.123.123.123)
4-08: 10:28:14.631 My Connections\cediti - SENDING>>>> ISAKMP OAK AG (SA, KE, NON, ID, VID 5x)
4-08: 10:28:14.801 My Connections\cediti - RECEIVED<<< ISAKMP OAK AG (SA, VID 3x, KE, NON, ID, HASH, VID, NAT-D 2x)
4-08: 10:28:14.801 My Connections\cediti - Peer is NAT-T draft-01 capable
4-08: 10:28:14.801 My Connections\cediti - NAT is detected for Client
4-08: 10:28:16.030 My Connections\cediti - SENDING>>>> ISAKMP OAK AG *(HASH, NAT-D 2x, NOTIFY:STATUS_INITIAL_CONTACT)
4-08: 10:28:16.030 My Connections\cediti - Established IKE SA
4-08: 10:28:16.030 MY COOKIE 1 51 a1 4 ca 7 2 dc
4-08: 10:28:16.030 HIS COOKIE ca 50 a0 a2 37 c6 3d 6d
4-08: 10:28:16.119 My Connections\cediti - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:23.032 My Connections\cediti - RECEIVED<<< ISAKMP OAK TRANS *(Retransmission)
4-08: 10:28:30.025 My Connections\cediti - RECEIVED<<< ISAKMP OAK TRANS *(Retransmission)
4-08: 10:28:30.454 My Connections\cediti - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:30.604 My Connections\cediti - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:30.604 My Connections\cediti - Received Private DNS Address = IP ADDR=10.128.8.22
4-08: 10:28:30.604 My Connections\cediti - Received Private Alt DNS Address = IP ADDR=10.130.8.3
4-08: 10:28:30.604 My Connections\cediti - Received WINS Address = IP ADDR=10.128.8.22
4-08: 10:28:30.604 My Connections\cediti - Received Alt WINS Address = IP ADDR=10.130.8.3
4-08: 10:28:31.835 Virtual Interface constructed for local interface 192.168.10.23
4-08: 10:28:31.915 Virtual Interface added: 192.168.10.23/255.255.255.0 on ISDN "SafeNet VA miniport".
4-08: 10:28:31.915 My Connections\cediti - Received Private IP Address = IP ADDR=192.168.10.23
4-08: 10:28:31.925 My Connections\cediti - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:31.925 My Connections\cediti - RECEIVED<<< ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:31.925 My Connections\cediti - IKE Extended Authentication successful.
4-08: 10:28:31.925 My Connections\cediti - SENDING>>>> ISAKMP OAK TRANS *(HASH, ATTR)
4-08: 10:28:32.025 My Connections\cediti - Initiating IKE Phase 2 with Client IDs (message id: CE8BD4CF)
4-08: 10:28:32.025 Initiator = IP ADDR=192.168.10.23, prot = 0 port = 0
4-08: 10:28:32.025 Responder = IP ADDR=10.153.8.10, prot = 0 port = 0
4-08: 10:28:32.025 My Connections\cediti - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID 2x)
4-08: 10:28:32.055 My Connections\cediti - RECEIVED<<< ISAKMP OAK QM *(HASH, SA, NON, KE, ID 2x, NAT-OA)
4-08: 10:28:32.095 My Connections\cediti - Filter entry 3: SECURE 192.168.010.023&255.255.255.255 010.153.008.010&255.255.255.255 081.246.000.010 added.
4-08: 10:28:33.227 Route 10.153.8.10->192.168.10.23 added.
4-08: 10:28:33.227 My Connections\cediti - SENDING>>>> ISAKMP OAK QM *(HASH)
4-08: 10:28:33.297 My Connections\cediti - Loading IPSec SA (Message ID = CE8BD4CF OUTBOUND SPI = 3405DF86 INBOUND SPI = 2DA10780)

André.

VPN Client through BSD

Anonymous3 (not verified)
on
June 21, 2005 - 9:13am

Here are some examples - OpenBSD should be able to pass ipsec w/o NAT
#vpn stuff
pass out on $ext proto esp from any to any keep state
pass in on $ext proto udp from any to any port = isakmp keep state
pass in on $ext proto esp from any to any keep state

#example 2
#proto 51 used for AH - Authentication Header
> pass in on fxp0 proto 51 from aaa.aaa.aaa.aaa to any
#proto 50 used for ipsec
> pass in on fxp0 proto 50 from aaa.aaa.aaa.aaa to any
#udp 500 used for key exchange
> pass in on fxp0 proto udp from aaa.aaa.aaa.aaa to any port = 500

Aha! Had same problem, and

Anonymous (not verified)
on
November 25, 2005 - 12:25am

Aha!

Had same problem, and this worked for me:

# add this as the last rule in the block filtering traffic
# from the hot network into the firewall
pass in on $ext proto udp from any to any port = isakmp keep state
pass in on $ext proto esp from any to any keep state
# from the firewall into the hot network
pass out on $ext proto esp from any to any keep state

# from the trusted network into the firewall
pass in on $int proto udp from any to any port = isakmp keep state
pass in on $int proto esp from any to any keep state
# from the firewall into the trusted network
pass out on $int proto esp from any to any keep state

Thanks, thanks, thanks!
alsq

Working Without Problem

SAB (not verified)
on
July 25, 2006 - 7:30am

I have a Nortel VPN Client with IPSec on XPpro passing through OpenBSD 3.9 Firewall without problem. Also I tried with Hamachi it also worked without any tweaking.

I am wondering when it comes to IPSec why it does not require any modification? Why it blindly allowing the traffic?

Regards
SAB

debugging

LennieNotLoggedIn (not verified)
on
February 6, 2008 - 10:11pm

When you want to know what is going on, you need to look at pflog:

# tcpdump -evnpti pflog0

it will point you to the rule that did the blocking.

But you need to have a log part in your rule:

block in log quick on ... etc.

I actually use a macro for the 'log' part, so I can turn them on or off.

Yep, the NAT 500 -> 500 worked for me also

Anonymous (not verified)
on
March 10, 2008 - 4:58pm

It threw me for a bit because I could connect for a few minutes then it would fail, but adding the NAT for port 500 has fixed my connection dropping.

Thanks for this posting!

thank you

Jose J Rivero (not verified)
on
February 4, 2008 - 2:50pm

Tha last post did it. 10000 Thanks!

Thanks, it helped me as

on
March 5, 2008 - 10:55am

Thanks, it helped me as well.

Use no-df

Larry Wimble (not verified)
on
May 31, 2008 - 4:14pm

Had this problem too. Make sure you:

scrub in all no-df

Larry

why should it help in this case?

sileNT (not verified)
on
June 1, 2008 - 11:43am

why should it help in this case?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.