Issues Using Forticlient behind an OpenBSD Firewall to connect to a Fortigate IPSEC VPN Server
Siju George writes: All outbound TCP, UDP and ICMP traffic from the LAN is let out through PF. I am able to connect to another Fortigate IPSEC VPN Server on the Internet using Forticlient on the same XP system but no data communication happens between them. I tried connecting from a network that is not firewalled by OpenBSD and the VPN connection to the same Fortigate Server is working fine and I am able to access the internal machines. Is there any other traffic I should allow other than TCP,UDP,ICMP on the firewall to connect and pass traffic between the Fortigate VPN server and the XP system using Forticlient? You didn't indicate whether the OpenBSD 4.0 is doing NAPT for your XP box or you have a binat setup. If NAPT then you must enable NAT traversal on the FortiGate. If you have setup a binat then you have the choice of enabling NAT traveral on the FortiGate or modifying pf to allow ESP (protocol 50) inout.
Re: GRE over IPsec
Chris Jones writes: I may have been mistaken. I just pulled this information from this document which Gregory Lebovitz from Netscreen co-authored back in 2003. No FortiGate model supported GRE in 2003, it wasn't added until 2006. On page 46 he talks about using GRE to create a virtual routing interfaces AKA tunnel interface. I have configure route-based VPNs between a Netscreen and FortiGate which interop just fine, which leads me to believe that they are using the same approach to tunnel interfaces. They are using the same approach, it just isn't GRE based. Both FortGate and Netscreen allow you to define a IPsec interface which has the routing benefits described in http://www.isi.edu/div7/presentation_files/dynamic_routing.pdf but which is also compatible with anything that supports tunnel mode IPsec. I have yet to get this to work between an OpenBSD box and a FortiGate/Netscreen. I will look into the gif option to see if this will work. It isn't clear to me why you don't just use tunnel mode IPsec on OpenBSD, it is compatible with both FortiGate and Netscreen. The gif approach is going to be a problem unless you have an IKE daemon that can negotiate tunnel mode (because that's what the FortiGate will expect) but actually use tranport+IPIP as per the RFC draft referenced in the above.
Re: GRE over IPsec
Stuart Henderson writes: interesting; if my understanding of this and the RFC that the referenced 'touch' draft was published as (rfc3884), at one end you can configure one side in *transport* mode carrying ipip encapsulated packets - gif(4) with net.inet.ipip.allow=1, afaict - and the other side in tunnel mode as usual. That's the idea, though the IKE daemon on the transport+IPIP side has to actually offer tunnel mode or the other end will typically reject the negotiation. this could be useful for either running routing protocols over IPsec, or for redistributing IPsec routes into an IGP (the latter being something I've been wondering about how to handle in some way that's a little more flexible than configure all of concentrator X's tunnels within 10.X/16 and all of concentrator Y's tunnels within 10.Y/16...) It is useful for all of the above.
GRE over IPsec
Chris Jones writes: Fortigates and Netscreens both use GRE interaces as tunnel interfaces when creating route-based VPN tunnels. FortiGates do not use GRE interface when creating route-based VPN tunnels. The route-based VPN on a FortiGate creates packets that are identical to IPsec tunnel mode i.e. IP|ESP|IP. As far as I'm aware, Netscreen do the same. Are you sure you don't have any Cisco's in your network? They use GRE for IPsec unless you've got a farily recent version of IOS that supports the virtual interface approach. Right now I have a hub-and-spoke VPN network using static routes to route traffic across the VPN. Each spoke endpoint has a static destination route of 10.1.0.0/16 which is sent over GRE interface. The only exception to the hub-and-spoke VPN is my OpenBSD firewall which I have to create VPN tunnels to every spoke network I need access to (quite painfull). On my OpenBSD box I would like to be able to use a single static destination route of 10.1.0.0/16 to send this traffic over a GRE interface to get to the rest of the VPN network. Since the FortiGate doesn't use GRE for IPsec (unless you configured it for some reason) then there is no need to use GRE on OpenBSD. Just define a normal tunnel based IPsec connection (as if the other end was another OpenBSD box). If you really want an interface so that you can route over it, then you'd have better luck with a gif interface. In that case if you can get the tunnel to come up you could run RIP/OSPF/iBGP on the OpenBSD gif interface and on the FortiGate IPsec interface and not use static routing at all.
VPN stability issues with a Fortigate peer
Chris Jones writes: I'm running the release version or OpenBSD 4.0 on my firewall and experiencing some odd IPSEC VPN behavior when connecting to a Fortigate peer. The tunnel will come up just fine but will randomly go down and then come back up and will continue this cycle. Unfortunately both FortiGate and OpenBSD don't follow Postel's advice to be liberal in what you accept (OpenBSD) and conservative in what you send (FortiGate). RFC 3706 section 5.3 says that the DOI SHOULD (not MUST) be 1. When the FortiGate sends a DPD with a DOI of 0, OpenBSD rejects it because that sends it to the ISAKMP handler which drops NOTIFY messages (see annotated trace below). If you only need DPD on one end and OpenBSD will send a DPD Vendor ID without trying to send a DPD (I haven't checked) then you can leave DPD enabled on the FortiGate and disable it OpenBSD. If that won't work or isn't acceptable (won't work too well if the FortiGate is configured with a dynamic connection) then to get FortiGate and OpenBSD DPD to interoperate you'll need to get one or both of FortiGate and OpenBSD to change their code. For FortiGate, send email to their customer support. In the case of OpenBSD maybe it is as simple as copying over the DPD message parsing from src/sbin/isakmpd/ipsec.c:ipsec_responder and put it in src/sbin/isakmpd/isakmpd_doi.c:isakmp_responder. BTW Cisco IOS (12.4) does follow the be liberal in what you accept recommendation in this case and will accept a DPD with a DOI of 0 from a FortiGate (though it will log a warning for DPD R U THERE). I am running isakmpd with the -K option and using ipsecctl to establish flows and SA's. This is what my ipsec.conf looks like: remote_gw = 10.1.1.1 flow esp from 192.168.8.1/32 to 192.168.0.0/16 peer $remote_gw type bypass ike dynamic esp from 192.168.8.0/24 to 192.168.0.0/16 peer $remote_gw \ aggressive auth hmac-sha1 enc 3des group modp1536 \ quick auth hmac-sha1 enc 3des group modp1536 \ srcid [EMAIL PROTECTED] \ psk sharedsecret The peer is DPD capable and enabled with the following settings: retry-count: 3 retry-interval: 5 After running isakmpd in debug mode (isakmpd -d -DA=50 -K) and after running ipsecctl I issued a continuous ping to one of the hosts at the other side of the tunnel. The ping ran fine for a period of time and then stopped. Here is the ouput from the debug: 073059.683292 Cryp 30 crypto_decrypt: after decryption: 073059.686654 Cryp 30 0118 fbbe1146 c43cf921 dc386a4a 0dfc2751 e4cf2a6d 0a34 0001 073059.689438 Cryp 30 0001 0028 01030401 f286fdea 001c 0103 80010001 800204b0 073059.692737 Cryp 30 80040001 80050002 80030005 0414 c5664590 c4700a67 9cec6a71 633ffd8c 073059.695546 Cryp 30 05c4 6214a4ed 31ca88ca 0945b3d6 dd2c44ef d03b008d 72b5ea00 273d3e0a 073059.698996 Cryp 30 5ec40d98 02c0ebad e3eac805 f87fa1ee 1142e2fd 92aee043 09e84e1c 3788c268 073059.701817 Cryp 30 4fdab8c6 1cbfad15 8123a459 df7a9a3b 66db84c5 59211ec4 90882bfc 2ae61c66 073059.705109 Cryp 30 6d35acdf 585d0b08 c5560cf9 d4a996a7 32a18daa d3385206 7ce49f52 f5bab82c 073059.707999 Cryp 30 12b6cc01 29fec19b 3f582995 e80637b4 5e99d396 3a3b650b 2d78dd5f 44879af5 073059.711332 Cryp 30 1f8e016d 27c69817 341c6984 52e4f663 175db8ba c206fb2b 08b9d0df f46705c1 073059.714125 Cryp 30 5a7d0a5a 0510 0400 0a4c0800 ff00 0010 0400 0a4c 073059.717252 Cryp 30 073059.719573 Mesg 50 message_parse_payloads: offset 28 payload HASH 073059.722425 Mesg 50 message_parse_payloads: offset 52 payload SA 073059.724772 Mesg 50 message_parse_payloads: offset 104 payload NONCE 073059.727806 Mesg 50 message_parse_payloads: offset 124 payload KEY_EXCH 073059.730126 Mesg 50 message_parse_payloads: offset 320 payload ID 073059.733027 Mesg 50 message_parse_payloads: offset 336 payload ID 073059.735500 Mesg 50 message_parse_payloads: offset 64 payload PROPOSAL 073059.738492 Mesg 50 message_parse_payloads: offset 76 payload TRANSFORM 073059.740835 Mesg 50 Transform 1's attributes 073059.743665 Mesg 50 Attribute SA_LIFE_TYPE value 1 073059.745973 Mesg 50 Attribute SA_LIFE_DURATION value 1200 073059.749044 Mesg 50 Attribute ENCAPSULATION_MODE value 1 073059.751324 Mesg 50 Attribute AUTHENTICATION_ALGORITHM value 2 073059.754161 Mesg 50 Attribute GROUP_DESCRIPTION value 5 073059.757008 Mesg 40 ipsec_validate_id_information: proto 0 port 0 type 4 073059.761190 Mesg 40 ipsec_validate_id_information: IPv4 network/netmask: 073059.763556 Mesg 40 0a4c0800 ff00 073059.766532 Mesg 40 ipsec_validate_id_information: proto 0 port 0 type 4 073059.768913 Mesg 40 ipsec_validate_id_information: IPv4 network/netmask: 073059.771838 Mesg 40 0a4c 073059.774860 Misc 20 ipsec_decode_transform: transform 1 chosen 073059.778019 Cryp 50 crypto_update_iv: updated IV:
ipsec vpn: freebsd and openbsd
kintaro oe writes: I'm setting up ipsec/vpn on freebsd and openbsd. I try to read this how to http://www.securityfocus.com/infocus/1859 but this applies to 2 openbsd systems. could anyone help me on how to setup between two systems? Type man vpn on your OpenBSD box and read the section on Configuring the Keying Daemon [automated keying]. That explains the gory details that ipsecctl and ipsec.conf deliberately hide from you. The reason for needing the gory details is that while FreeBSD has an /etc/ipsec.conf, its format is different from OpenBSD and it doesn't have helpful defaults so you need to specify everything exactly. The FreeBSD documentation makes a reasonable stab at explaining how to do this at :- http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html But ignore any mention of gif, and stick with a simple tunnel mode connection as described by the summary at the very end. You could also look at the following Linux documentation which explains how to configure Racoon, the same IKE daemon that is used on FreeBSD :- http://www.ipsec-howto.org/x299.html Finally the following show is an old document covering how to make OpenBSD and NetBSD IPsec interoperate and since NetBSD also uses Racoon you can use that as a template for the FreeBSD configuration ... http://www.rommelwood.de/~hshoexer/ipsec-howto/HOWTO.html
