IPSEC VPN Using Private IP, point-to-point

[kentbsece]

Hello,

I'm currently building a site-to-site IPSEC VPN but I would like to know if its possible to use a private IP (10.10.10.0/30) network. Below is my current configuration.

Firewall A:

Port 10: 10.10.10.1/32 Firewall B: Port 9: 10.10.10.2/32

Both port interface is connected using a cross-cable.

Problem: I tried to create an IPSEC - Phase 1 but the tunnel is still down.

Thank You

[ede_pfau]

hi,

and welcome to the forums.

The value of the WAN addresses don't matter. If you're using a PSK, make sure it is identical on both sides (this is IMHO the most common error in failing VPN setups). In phase2, the Quick Mode selectors should be more specific than the '0.0.0.0/0' defaults.

If you need more support, please post the phase1 and phase2 config, along with the policy and the static route which are needed for this to work.

[rwpatterson · Accepted solution]

Make sure you build the policies. The tunnels will not come up unless the interesting traffic is requested by policies.

[kentbsece]

rwpatterson wrote:

Make sure you build the policies. The tunnels will not come up unless the interesting traffic is requested by policies.

I tried to build the Phase 2 and it works. My tunnel is now open. I guess phase 2 as well as the policies must be build to established the tunnel.

Cheers!

[ede_pfau]

@oheigl:

I generally prefer to avoid wildcards. When setting up a site2site VPN I know in advance which networks are involved. Pinning down the traffic to 'known' networks has a security aspect as well: introducing rogue devices with arbitrary network addresses (like the unbeatable 192.168.0.x) will not have any effect on VPNs then.

Of course, this can be controlled in the corresponding policy as well. In fact, it should be and usually is.

Besides, one look into the phase2 documents which traffic is meant to cross the link.

One more reason: the wildcard '0.0.0.0/0' is AFAIK Fortinet specific. Other vendors like Cisco require explicit subnet specs. So, it will work between FGTs (albeit with less control) but not if one side uses or changes to use a non-FTNT device.

[emnoc]

 wildcard '0.0.0.0/0' is AFAIK Fortinet specific.

JunosSRX also defaults to a 0.0.0.0/0  also. If your  using a route-base lan ( which is recommended ) It probably does not matter  if you use wildcard or specific proxy-id.

If you ever connect to something non-Fortigate/Juniper than specific  src/dst-subnets are required.

e.g 

ciscoASA

pfSense

checkpoint

PaloAlto

watchguard

etc

[ede_pfau]

Thx Ken, I was sure you knew all the other vendors...

In python they say "explicit is better than implicit", there's a point to it...

[emnoc]

agreed 100%

The problem is ;1> FTNT  KB/DOCs always demonstrates  a 0.0.0.0/0:0  in  most site2site vpn examples  2> in FTNT training classes  &  when they do the site2site w/OSPF they demo 0.0.0.0/0:0   3> wildcard will work for  all address and services,  but its MORE  ideal to at least set the  type as subnet and then specificy the exact    src/dst-subnets ( aka local/remote networks )

IMHO  the 0.0.0.0/0:0  is just a lazy way of doing it,  but it does have  it's PROs

1: it's a one-time cfg ( you never have to add multiple   phase2-interfaces for other ranges that you latter want to  encrypted , just ensure routes for the remote-vpn are in placed or added as required  )

2: you can't screw it up ;) ( it's idiot proof to some degree )

CONs

1: It leaves you  no specific  show diagnostics outputs  for  per-local/remote vpn networks

2: make  for more troubleshooting if just one local/remote networks connectivity is working or not without using  diag sniffer or diag flow commands

3: it won't work for other  firewalls that hates proxy-ids that have 0.0.0.0/0   as mention before ( e.g cisco ASA, openSense,Pfsense,checkpoint,etc.....)

I always try to stress  the specific local/remote subnets with all my associates and  avoid the easy and lazy way of a 0.0.0.0/0:0

;)

YMMV

Ken

[MikePruett]

Yeah, I hate using quad 0 for source destination on phase 2s. I understand why Fortinet documentation uses it though. It is quick and easy. Most people don't need anything more.

[oheigl]

I get your points, but if you have to deal with remote sites with many different networks, the configuration takes way longer, and also to change encryption parameters in the future is more work too.

I think there are a few vendors out there which support quad 0, but most of the technicians don't know how to configure it. Palo Alto for example also uses quad 0 as a default setting, but anyway, everybody should do it like he wants