Fortigate IPSEC route-based and Linux

Q: A manual for what ipsec ( client /server ) site2site ,etc... Are you familiar with strong or freeswan or racoon ? I would suggest you manpage those items b4 moving down that line. THe process is no different than any ipsec-vpn i.e define the basic security method for authentication of the peers ( certs or PSK ) define phase1 proposal and ike version i.e esp-3des and ikev1 md5, esp-aes192 ikev1 sha define phase2 proposals to include or not include pfs optional define the traffic rules to allow traffic from peer a to peer b left-subnet /right-subnet aka local / remote define any additional kernel routes additive " ip add" and other ip commands etc... Strongswan is very well support and straight support if your kernel is built correctly. My experience has been with 2.6 kernels or using the open community Vyatta offerings which is nothing but a big wrapper around iptables, quagga, strongswan, squid, and a few other pkgs. fwiw, Biggest problem with doing strongswan on a linux host is iptables is overlooked 99% of the time and that' s where 99.99% of your problems are at. the ipsec.conf and secret file is the simply issue to overcome Good luck

i familiar with openswan\strongswan and racoon also.. i always build a classic site-to-site vpn and everything is okey right now i should build VPN with Fortigate which are configured in route-based. so topology: REMOTE NETWORK (192.168.1.0/24) - FORTIGATE ----- internet ----- LINUX (behind NAT) ---- MY LOCAL NETWORK (192.168.2.0/24) IPSEC IP TUNNEL on side Fortigate - 10.0.0.1 IPSEC IP TUNNEL on side Linux - 10.0.0.2 The main problem - where i should put this 10.0.0.2 on linux side? Fortigate are using route-based method for internal routing protocol (ospf i think) can you provide example of config (raccon\stronswan) for route-based configuration? thank u!

!st the fortigate could care less if your FGT is policy or route-based mode. 2nd, if your behind NAT ( assuming that' s what you meant ) , than the linux host needs to be made aware or NAT-T in the ipsec.conf global section 3rd if you ment the local-subnet is to be NAT' s b4 going across the table, than deploy iptables with the approp pre-route rule and whatever you NAT it into would be the network you define on the FGT for the " remote" subnet ( linux ) basically you will looking something like this; conn %default keyexchange=ikev2 keyingtries=0 conn mygate001_DigiPort-MIAMI auto=start left=%defaultroute leftsubnet=172.88.98.0/24 right=192.168.111.2 rightsubnet=192.34.18.0/24 pfsgoup=modp1024 A stated b4 linux has no concept of your fgt/juniper being policy/routed based mode vpn-ipsec and could care less. Just match your FGT to the LINUX host in your proposals and ensure your PSK is match. If your on a cert for authentication, it can be quite challenge on your 1st go away but remember to build your certs on the same sign' ing key and then copy that certs over to the fgt and import it. One tidbit, anything in the global section is just that global, and if you apply a unique parameter under any connections, that overrides the global for that " session" btw if you make any attempts at a l2tp/ipsec with strongswan or anything opensource, post the cfg for all to see. good luck

I have only one question. Where i should put a virtual IP in openswan/raccon? I have all remote networks I know public IP of both side. I don' t understand how to put identity to ipsec-tunnel for route-based policy Please look on my topology which i write above.

Do you really need a VIP? or can you do something like prerouting ( DNAT ) within iptables ? e.g -A prerouting -p all -j dnat --to 192.168.2.222 I' m still lost at what/why a VIP in this scenario, if you want all of the left subnet 192.168.1.0/24 to speak to right subnet 192.168.2.0/24 then just add that into the appliances for src/dst dst/src and define your policies. If you want to hide or mask the clients behind an address and present that one address into your src/dst dst/src proxy ids, than you have to experiment with some prerouting rules ( DNAT ) and change the address on the end of the ipsec tunnel if that' s what you really want. It can' t be too hard, if you fail and fall off the horse, climb on and try again

Okey.. i will explain. 1. i don' t have overlapping networks... left side should have access to right side without any NAT. 2. On fortigate i have a configuration that enable route-based policy. To enable Route-based policy i must select virtual-interface on the fortigate (which was created manualy), IP assigned to this interfaces is fake (like 10.0.0.1) and put it to IPSEC configuration. Right now i see on fortigate IPSEC rules like from 0.0.0.0/0 to 0.0.0.0/0. But route-based policy provide ability to route traffic between many tunnel through the virutal-interface... As i understand on my second side i should do the same configuration? I must write in racoon something with 10.0.0.2 ip? Or not? There is no Iptables rules on Linux box. Linux box behind NAT (but i can forward any ports like 500,4500,esp ...) to my linux box.. so i believe this is not a problem. If i will put a standrat configuration on linux box for raccon - everything should work? Fortigate have 2 tunnel right now to two different location and they are using fake virtual interface. My goal is investigating and configuring on Linux box software raccon...

Just to clarify: when you create (!) an interface-based (a.k.a. route-based) IPsec VPN on a Fortigate you have check the first option in the advanced phase1 setup. Then, the FGT itself will create a virtual interface which can be used in a policy or in routing. You never create the interface yourself (I wouldn' t know how anyway). Secondly, these tunnel interfaces can be assigned an IP address but in 99% of the cases you don' t need to. Only if you want to ping the other tunnel end then of course you' d need addresses - but you could also ping a host on the remote subnet for that. Third, the Quick Mode selectors in phase2 should be as specific as possible. They determine which traffic is able to start a tunnel negotiation. You will see that the FGT will show the specified subnets as ' proxy addresses' in the VPN monitor. Finally, create a static route to the remote subnet, without entering a gateway address but specifying the tunnel interface. That should do it.

Thanks. One question: how OSPF will work on linux side and on fortigate side if there no interface? On Linux side i can install zebra\ospfd ... but it should have interface. Can someone explaine me this?

sorry, no Linux guru on this side... Do you really need OSPF over the tunnel?

Yes agreed, do you really need OSPF or routing information? in a route base approach the static route that your install to that vpn-tunnel interface is all that you need. I think your making it overly complex. btw, if you do run quagga/zebra on the LFW ( linux firewall ) and with ospf for example, the quagga/zebra ospf daemon, will inject the remote_subnet address as defined in your ipsec.conf file , into the OSPF process. So if you need reach locally for some downwind routers/firewall , they will learned this via ospf if you config it.