Accessing other networks through VPN

[DenJS]

Hello!

I'm trying to figure out how VPN things works in a company (I just joined and exam existing configs)

So we've got 100D as a core router & firewall & vpn server and several 30Ds as spokes.

Using a console on 100D I can access all local networks such as 192.168.10.0/24 and other network for which 100D has static routes, e.g. 192.168.80.0/24. 100D has one phase1-interface VPN and many phase2-interface configured for each spoke.

So spokes dial 100D and establish a VPN and from the console of each spoke I can ping 192.168.10.0/24 only but not 192.168.80.0/24 even if I have a static route on a spoke e.g. 192.168.80.0/24 -> VPN_to_100D

Could you please help to understands what's wrong with this configuration?

Many thanks in advance.

[ede_pfau]

Two things have to match to allow access to a remote network:

VPN / phase2 / Quick mode selectors / remote subnet

and

dest/source address in the policy on both the remote and the central FGT (on spoke: internal -> tunnel, hub: tunnel -> internal)

The QM selectors determine what kind of traffic is allowed to negotiate the tunnel setup.

On the spoke FGT,  use one phase2 for each subnet behind the hub FGT.

For a second subnet, on the spoke you just need to add

- a route

- a subnet address to the outgoing policy

Of course, the hosts in the second subnet behind the hub FGT should know where to find the remote hosts, usually by following their default route to the hub's FGT.

[DenJS]

Thank you for helping me.

So, if I create a rule/policy (and put them on top) on both FGT (inbound and outbound) with something like:

1. From: internal  To: VPN_to_HUB  Source: LocalLAN (192.168.55.0/24)  Dest: RemoteLAN (192.168.0.0/16)  ALWAYS  ALL ACCEPT

2. From: VPN_to_HUB To: internal  Source: RemoteLAN (192.168.0.0/16)  Dest: LocalLAN (192.168.55.0/24) ALWAYS  ALL ACCEPT

and so on... will this allow to access all networks within 192.168.0.0/16 from the spoke or I have to specify explicitly each subnet? Hopefully I shouldn't ;) Of course there are some routes on spokes like:

192.168.70.0/24 0.0.0.0 VPN_to_HUB and so on

and of course FGT installs some static routes when stablish VPNs... so on the HUB I can see a static route:

192.168.55.0/24 0.0.0.0 VPN_HUB

On the hub vpn setup looks like this:

FGT# show vpn ipsec phase1-interface 

config vpn ipsec phase1-interface

    edit "VPN_HUB"

        set type dynamic

        set interface "External"

        set ike-version 2

        set local-gw Hub_Public_IP

        set proposal aes192-sha1 aes128-sha1

        set psksecret ENC secret

    next

 

FGT# show vpn ipsec phase2-interface 

config vpn ipsec phase2-interface

    edit "VPN_Remote1_p2"

        set dst-addr-type name

        set keepalive enable

        set phase1name "VPN_HUB"

        set proposal 3des-sha1 aes128-md5

        set src-addr-type name

        set dst-name "RemoteLAN (55.0/24)"

        set src-name "LocalLAN (.0.0/16)"

    next

On the spoke vpn setup is like this:

FGTSPOKE # show vpn ipsec phase1-interface 

config vpn ipsec phase1-interface

    edit "VPN_to_HUB"

        set interface "wan"

        set ike-version 2

        set proposal aes192-sha1 aes128-sha1

        set remote-gw Public_IP_of_HUB

        set psksecret ENC secret

    next

end

FGTSPOKE # show vpn ipsec phase2-interface 

config vpn ipsec phase2-interface

    edit "VPN_to_HUB_p2"

        set auto-negotiate enable

        set dst-addr-type name

        set keepalive enable

        set phase1name "VPN_to_HUB"

        set proposal 3des-sha1 aes128-md5

        set src-addr-type name

        set dst-name "RemoteLAN"

        set src-name "LocalLAN"

    next

end

[ede_pfau]

@DenJS:

Correct. This is called a "supernet" where all subnets can be summarized to one network with a wider netmask. Smart move if you have the opportunity to create all spoke networks from scratch.

On the hub, you have "dynamic" routes, not static, as they are only inserted on tunnel-up. Which doesn't change a thing :)

As for the other suggestions later, I don't think changing from IKEv2 to IKEv1 will help much. Negotiations are longer, IKEv2 is relatively new and will best run between gateways of the same vendor...there are pros and cons. I'd stick with it unless this scheme could not be realized with IKEv2.

Personally, I avoid having a wildcard '0.0.0.0/0' address in the phase2 setup. Wildcards work between FGT and FGT sometimes but why not be specific? 'explicit is better than implicit'