Skip to main content
DenJS
DenJS
New Member
December 20, 2015
Question

Accessing other networks through VPN

  • December 20, 2015
  • 2 replies
  • 3756 views

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.

    2 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    December 21, 2015

    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
    DenJSAuthor
    New Member
    December 21, 2015

    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
    SuperUser
    ede_pfau
    SuperUser
    December 22, 2015

    @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'

    Terms & ConditionsAccessibility statement