Search This Blog

Wednesday, September 12, 2012

Fortigate IPSec VPN client for iPhone with two different groups


In the following post I will describe how to configure Fortigate IPSec VPN for iPhone clients with 2 different authentication groups.

For this post I used Fortigate FGT60B with FortiOS v4.0, build0521, 120313 (MR3 Patch 6).
1.       Create user account:


CLI config:

config user local
   edit "test1"
      set status enable
      set type password
      set passwd <password>
end

 
2.       Create group:

 
 

 CLI config:

config user group
   edit "TEST-GRP-1"
      set member "test1"
end

 
3.       Create firewall address objects for VPN clients network:



In my example the VPN clients will be part of network 10.10.11.0/24

CLI config:

config firewall address
   edit TEST1-NETWORK
      set subnet <ip here subnet here> (ie: 10.10.11.0 255.255.255.0)
   next
 

 
4.       Create firewall address object for internal network (if you don’t already have one):



Here I use network 192.168.10.0/24 as my internal network

CLI config:

config firewall address
   edit LAN
      set subnet <ip here subnet here> (ie: 192.168.10.0 255.255.255.0)
   next
 

 
5.       Now we will configure IPSec phase-1 and phase-2, both will have to be configured from the CLI because some options are missing in the web GUI.

 
config vpn ipsec phase1-interface
    edit "TEST1-PH1"
        set type dynamic
        set interface "wan1"
        set dhgrp 2
        set peertype one
        set xauthtype auto
        set mode aggressive
        set mode-cfg enable
        set proposal aes256-md5 aes256-sha1
        set peerid "test1"
        set authusrgrp "TEST-GRP-1"
        set ipv4-start-ip 10.10.11.1
        set ipv4-end-ip 10.10.11.254
        set ipv4-netmask 255.255.255.0
        set psksecret <tunnel password here>
end 

 6.       Phase-2 configuration:

config vpn ipsec phase2-interface
    edit " TEST1-PH2"
        set keepalive enable
        set pfs disable
        set phase1name " TEST1-PH1"
        set proposal aes256-md5 aes256-sha1
end 

 7.       Configure firewall policy rule which allow access from VPN client network to internal network

 

 CLI config:

config firewall policy
    edit <unique firewall policy ID here>
        set srcintf "TEST1-PH1"
        set dstintf "internal"
        set srcaddr "TEST1-NETWORK"
        set dstaddr "LAN"
        set action accept
        set schedule "always"
        set service "ANY"
    next 

 

8.       Configure firewall policy rule which allow access from internal network to VPN client network



CLI config:

config firewall policy
    edit <unique firewall policy ID here>
        set srcintf "internal"
        set dstintf "TEST1-PH1"
        set srcaddr "LAN"
        set dstaddr "TEST1-NETWORK"
        set action accept
        set schedule "always"
        set service "ANY"
    next 

9.       Configure static route with VPN clients network as destination and IPSec phase-1 as next-hop

 
 CLI config:

config router static
        edit <unique route ID>
        set device "TEST1-PH1"
        set dst 10.10.11.0 255.255.255.0
end

 
10.   Configure iPhone VPN client, go to Settings -> General -> Network -> VPN and click on Add VPN Configuration…

11.   Choose IPSec and fill the required information below:

Description
Short quick description of the VPN
Server
WAN IP address of the FGT unit
Account
User name
Password
Password of the user
Group name
Peer id value which was configured on step 5
Secret
PSK value which was configured on step 5

 



12.   Now slide the VPN button and connect to your network using IPSec

 



 13.   Repeat steps 1 to 12 to configure another account with different group, note that the peer ID value is responsible for differentiate each group.

Sunday, September 9, 2012

BGP filtering using extcommunity


Let’s have the following scenario:

R4/AS65004 is the source for networks 192.168.41-45.0/24, where R5 is just binding between R2 and R3. Now the current situation is where everyone advertises all the networks to everyone…

R5 is also doing prepending toward R2 as part of AS65005 policy.

The result:

-          R1 learns the following networks directly from R4

-          R3 learns the following networks directly from R4

-          R2 learns the following networks from R1

R2#sh ip bgp
BGP table version is 34, local router ID is 10.1.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
*  192.168.41.0     10.1.25.5                              0 65005 65005 65003 65004 i
*>                  10.1.12.1                              0 65001 65004 i
*  192.168.42.0     10.1.25.5                              0 65005 65005 65003 65004 i
*>                  10.1.12.1                              0 65001 65004 i
*  192.168.43.0     10.1.25.5                              0 65005 65005 65003 65004 i
*>                  10.1.12.1                              0 65001 65004 i
*> 192.168.44.0     10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.45.0     10.1.25.5                              0 65005 65005 65003 65004 i

 Now let’s have R4 lost his link to R1 by shutting it down, in this case R2 will continue to prefer R1 as next-hop for these networks and R1 will become transit.

R2#sh ip bgp
BGP table version is 42, local router ID is 10.1.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.41.0     10.1.12.1                              0 65001 65003 65004 i
*                   10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.42.0     10.1.12.1                              0 65001 65003 65004 i
*                   10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.43.0     10.1.12.1                              0 65001 65003 65004 i
*                   10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.44.0     10.1.12.1                              0 65001 65003 65004 i
*                   10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.45.0     10.1.12.1                              0 65001 65003 65004 i
*                   10.1.25.5                              0 65005 65005 65003 65004 i

 R1 can’t control other AS’s BGP policy and AS65001 must learn AS65004 networks in order to be able to reach them.

So here is a very simple solution: R1 will mark each BGP peer learned prefixes with special extended community and will avoid advertising prefixes learned from one peer to the other.

First configure the extended community:

ip extcommunity-list 2 permit rt 222:222
ip extcommunity-list 3 permit rt 333:333

 Then configure an outbound route-map, for each peer:

route-map R2_OUTBOUND deny 10
 match extcommunity 3
route-map R2_OUTBOUND permit 20
!
route-map R3_OUTBOUND deny 10
 match extcommunity 2
route-map R3_OUTBOUND permit 20

And inbound route-map, for each peer:

route-map R2_INBOUND permit 10
 set extcommunity rt 222:222
!
route-map R3_INBOUND permit 10
 set extcommunity rt 333:333

Finally apply these route-maps to each peer:

Router bgp 65001
neighbor 10.1.12.2 route-map R2_INBOUND in
neighbor 10.1.12.2 route-map R2_OUTBOUND out
neighbor 10.1.13.3 route-map R3_INBOUND in
neighbor 10.1.13.3 route-map R3_OUTBOUND out

R1 will mark R2 and R3 learned prefixes in extended community rt 222:222 and 333:333 respectively and will deny advertise them based on the opposite extcommunity.

The result:

R2#sh ip bgp
BGP table version is 47, local router ID is 10.1.123.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.41.0     10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.42.0     10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.43.0     10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.44.0     10.1.25.5                              0 65005 65005 65003 65004 i
*> 192.168.45.0     10.1.25.5                              0 65005 65005 65003 65004 i

Although R1 can’t control R5 policy he can avoid being transit in case of failure of directly peer.

Marking peer prefixes with extcommunity can help for many route manipulations and policies and provide better control.