Tuesday, October 16, 2018

Windows 10 Holds on to an IP address for dear life!


Came across an interesting, and horribly annoying, behavior with Windows 10..and probably any recent version of Windows. Windows will ALWAYS try to reuse the last successful dhcp lease it receives, even across reboots! So you may ask, why should I care about this? Well, if you are in say a school campus environment, with domain-ed clients, that are shared by students and faculty, which in turn are placed on different vlans...this behavior will indeed create havoc! The ip leased by say a student, will "stick" in the registry, and as long as the dhcp lease is still valid, it will be reused. Now a faculty member logs on, they end up associated to an AP and get assigned the faculty vlan at layer 2...but are stuck with an IP from the student vlan that's invalid for the that subnet.

The interface ip lease information is stored here (see example reg values below)



HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}

"DhcpIPAddress"="10.2.21.28"

"DhcpSubnetMask"="255.255.252.0"

"DhcpDomain"="mydomain.local"

"DhcpNameServer"="10.1.2.19 10.1.2.17"

"DhcpDefaultGateway"=hex(7):31,00,30,00,2e,00,32,00,2e,00,32,00,30,00,2e,00,31,\
00,00,00,00,00

"DhcpSubnetMaskOpt"=hex(7):32,00,35,00,35,00,2e,00,32,00,35,00,35,00,2e,00,32,\
00,35,00,32,00,2e,00,30,00,00,00,00,00

This key is changed to the broadcast address from 10.1.2.19

"DhcpServer"="255.255.255.255"


And like I mentioned...this is stored across reboots.

The various ways to "reset" or clear these reg key values are as follows:
 
ipconfig /release from an active connection under the current session then log off or shutdown- ready for the next user

Log in as an administrative user and restart\stop the DHCP service- then log off or shutdown.

Neither option is particularly easy to trigger and schedule via a scheduled task....so what I ended up doing was multi-layered approach. I needed the above reg values to be cleared whether the machine was connected to the network or not...so this meant dropping the scripts locally. I used group policy preferences in a GPO to do that. 2 files, one the PS script to clear the reg...which is also searches for the correct interface GUID based on the name of the network connection...in our case "WiFi"

cd\cls$ErrorActionPreference='silentlycontinue'$NIC=Get-WmiObject -class Win32_NetworkAdapter -Filter "NetConnectionID='Wi-Fi'" | select -Property GUID -ExpandProperty GUID #needed to just get string wo headerRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpIPAddressRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpSubnetMaskRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpDomainRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpNameServerRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpDefaultGatewayRemove-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC -Name DhcpSubnetMaskOptSet-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\$NIC" -Name DhcpServer -Value 255.255.255.255exit

The other, a one liner cmd script to trigger the ps script:


C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy bypass -file C:\users\IPReleaseV3.ps1


The latter script, I used the same computer based GPO configured with a shutdown script referencing the local cmd script....so once the domained machine has the GPO associated and applied, the script will trigger on shutdown or restart whether on the network or not.....which is what we want.

C:\users\IPRelease.cmd

I seemingly had it licked now...but found out that thanks to Windows Hiberboot or Fast Startup they call it, a shutdown script will NOT be processed on shutdown ! It will just be skipped. On restart it does seem to execute though.

Anyway...I went ahead and pushed the following reg setting to disable Hiberboot..again, using GP preferences:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\

HiberbootEnabled=0


So there you have it...a bit of a clunky solution but an absolute life saver in our situation. 

Hope somebody finds this helpful ! 





Sunday, August 2, 2015

Unable to advertise static routes via MP BGP to PE routers

Wanted to quickly post this MP BGP MPLS config I had trouble with here. Below is the Cisco support thread that covers it.



I wanted to do a straight bgp only L3 service across my ISP PEs....using different AS for each customer site. No other core IGP is used- just BGP and static routes to form the neighborships between PE-R8 and PE-R9. In order to get full end to end connectivity for the site networks, I had to advertise the transit networks between the PE routers and the P router. (the .140 and .144) The key to get them advertised out to the CEs was first get define the static routes on the PE in the global routing table. Then redistribute those into the ipv4 BGP table. THEN...import those routes into the customer vrf using the import command that references a route-map, that references an ip prefix-list to scope the routes. After all that- they finally appeared in the vpnv4 address family on the PE routers, and in BGP on the vrf attached CEs
This was the only way I could get them to work - maybe there's an easier way !


Unable to advertise static routes via MP BGP to PE routers


PE-R8#show ip bgp
  Network          Next Hop            Metric LocPrf Weight Path
 r>i 8.8.8.8/32       152.177.58.146           0    100      0 ?
 *>  9.9.9.9/32       152.177.58.141           0         32768 ?
 r>i 152.177.58.140/30
                             152.177.58.146           0    100      0 ?
 *>  152.177.58.144/30
                             152.177.58.141          
0         32768 ?
show ip bgp all
For address family: VPNv4 Unicast
Route Distinguisher: 120:120 (default for vrf TGI)
Import Map: IMPORT_STATIC_MAP, Address-Family: IPv4 Unicast, Pfx Count/Limit: 1/1000
 *>  10.7.1.0/24          152.177.58.138    0             0 65002 i
 *>i 10.24.20.0/22      9.9.9.9                  0    100      0 65001 i
 *>i 51.64.56.252/30  9.9.9.9                  0    100      0 65001 i
 *>i 130.148.200.126/32
                                  9.9.9.9                  0    100      0 65001 i
 *>i 152.177.58.132/30
                                 9.9.9.9                  0    100      0 65001 i
 r>  152.177.58.136/30
                                152.177.58.138           0             0 65002 i
 *>  152.177.58.144/30
                       152.177.58.141          
0         32768 ?


So..to sum up...here's the config that worked: (for PE-R8....R9 config'd similarly)

ip vrf TGI
rd 120:120
import ipv4 unicast map IMPORT_STATIC_MAP
route-target export 20:20
route-target import 20:20

router bgp 65000
bgp router-id 8.8.8.8
bgp log-neighbor-changes
neighbor 9.9.9.9 remote-as 65000
neighbor 9.9.9.9 update-source Loopback8
!
address-family ipv4
redistribute static
neighbor 9.9.9.9 activate
exit-address-family
!
address-family vpnv4
neighbor 9.9.9.9 activate
neighbor 9.9.9.9 send-community both
exit-address-family
!
address-family ipv4 vrf TGI
neighbor 152.177.58.138 remote-as 65002
neighbor 152.177.58.138 activate
exit-address-family

ip route 9.9.9.9 255.255.255.255 152.177.58.141
ip route 152.177.58.144 255.255.255.252 152.177.58.141
!
!
ip prefix-list IMPORT_STATIC seq 5 permit 152.177.58.144/30
!
route-map IMPORT_STATIC_MAP permit 10
match ip address prefix-list IMPORT_STATIC

Sunday, June 28, 2015

Windows VLAN Stripping - Intel(R) PRO/1000 PT Quad Port NIC w GNS3



It's been widely know that Windows OS's by default, will strip VLAN tags as they enter the stack. It's driver dependent really....and some nic driver are designed to cope with it, and some not. Luckily, my Intel(R) PRO/1000 PT Quad Port LP Server Adapter (aka "HP NC364T PCI EXPRESS QUAD-PORT GIGABIT SERVER ADAPTER") is able to deal with this annoyance with a couple of simple settings.

First, you want to set you Priority and VLAN settings to enabled for both..


























Second is a registry key and setting. In the case of the Intel Quad, there'll be 4 of these...one for each physical interface:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0006]

"MonitorModeEnabled"=dword:00000001


You want to create the DWORD value "MonitorModeEnabled" under the above key and set it to 1. Note that the numbered end of the key name "00nn" will be different on your system- one of mine is 0006.

That's it.... give your machine a reboot and you'll be passing VLAN tags through your Windows systems to your virtual machines or for example, GNS3 labs. This is huge to able able to attach your virtual GNS3 routers to say, your real physical switch stack and trunk VLAN tags as normal for labbing etc.....


As an example, I labbed a little MPLS network recently, and took a capture to make sure my physical laptop, plugged in to a real switch port in VLAN 40, was not having the tags stripped after the above changes.



I sent a ping from the laptop, through the switch port, out the trunk connected to my Quad 2 nic, into my GNS3 network....to the CE-5 loopback at 5.5.5.5...... proof that VLAN tags are now in tact!

Here's a capture of the ping below. And incidentally, you'll want to set your destination Cisco SPAN port with dot1q encapsulation, like this....or it will get stripped there as well. Hope this helps somebody....

monitor session 1 source interface Fa0/48

monitor session 1 destination interface Fa0/47 encapsulation dot1q









Sunday, May 24, 2015

Basic Campus Network with Cisco Packet Tracer


 

    As if there's not enough network diagrams and designs out there...here's one more! I wanted to just share out a basic campus network design using good old CPT. For all it's limitations and flakiness, it's still damm cool to have an entire functioning network, albeit somewhat dated, stuffed into a single pkt file! A good review and reference of some basic design principles using HSRP, splitting Vlan traffic among the distribution switches, gateway redundancy, split DHCP scopes... things like that. Even has a telephony router and some ip phones...not too shabby! I'll make the pkt file available too for anybody who wants to download the topology.







Download PKT File





Monday, March 9, 2015

DMVPN w GETVPN for encryption



I thought it would be cool to lab out a combination of DMVPN (Dynamic Multipoint VPN, utilizing multipoint GRE dynamic tunnels) with the integration of GETVPN. Group Encrypted Transport VPN, which utilizes a key server that distributes group keys to it's registered members and controls the group security associations between the peers. GETVPN does not use static ipsec tunnels or create the VPN frame work....you would need to have a vpn in place...DMVPN in this example, although GETVPN is best suited over MPLS.  BTW...a great guide for setting up and understanding DMVPN can be found here at firewall.cx:

CONFIGURING CISCO DYNAMIC MULTIPOINT VPN (DMVPN)


Below is my GNS 3 lab diagram. I started by using a single router to represent the internet. I also Port Address Translated the 2 spoke and hub routers public interfaces to allow the private hosts to communicate with the rest of the "Internet" to add some realism. The DMVPN config is below





------------------------------------------------------------------------------------------------------------------------

interface Tunnel0
 description mGRE DMVPN Tunnel





 ip address 192.168.1.1 255.255.255.0
 no ip redirects



 no ip split-horizon eigrp 1

no ip next-hop-self eigrp 1






ip nhrp authentication DMVPN

ip nhrp map multicast dynamic




 ip nhrp network-id 1


 tunnel source 11.11.11.1



 tunnel mode gre multipoint

router eigrp 1
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
These are the pertinent  parts of the DMVPN config. Nothing special with the physical interfaces- just assign them IPs and activate them. All the config is done on the tunnel interface- which is the fist thing you'll create.

This the hub config. You'll want to use a private address network for your tunnel interfaces.

You will definitely need to disable split-horizon for the EIGRP process running on the tunnel interface. If you don't, your spokes will never get eachothers routes, only the updates from the hubs routes will be present on the spokes. Also if you want direct communication\routes between spoke routers, and not send all traffic via the hub, then disable next-hop-self as well for your EIGRP,

Set your authentication string to allow queries and updates to the NHRP database

Map multicast traffic to the spokes dynamically- this is used and necessary for routing protocols that use multicast packets (ie EIGRP in this case) in their routing updates.

Set the network ID- which will be the same for all participating routers in the VPN cloud.

Your tunnel source is the public facing interface IP.

This command enables the tunnel interface as a multipoint GRE tunnel.

This is your basic advertising of your routers networks- you'll need to add the tunnel network as well in order for EIGRP adjacencies to form.

--------------------------------------------------------------------------------------------------------------------------
Next is the spoke config for the VPN........

--------------------------------------------------------------------------------------------------------------------------





interface Tunnel0
 description mGRE DMVPN Tunnel
 ip address 192.168.1.3 255.255.255.0
 no ip redirects
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp map 192.168.1.1 11.11.11.1
 ip nhrp map multicast 11.11.11.1
 ip nhrp network-id 1






 ip nhrp nhs 192.168.1.1

 tunnel source FastEthernet0/0
 tunnel mode gre multipoint

router eigrp 1
 network 10.3.3.0 0.0.0.255
 network 192.168.1.0
ip route 0.0.0.0 0.0.0.0 33.33.33.254


ip access-list extended NATISP
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 10.3.3.0 0.0.0.255 10.0.0.0 0.255.255.255
 permit ip 10.3.3.0 0.0.0.255 any

Almost the same thing for the spokes...but here are the differences:





Maps the hubs NHS tunnel IP to it's public IP

Send multicast traffic to the hub, so that the hub processes it- this is essential for EIGRP to form adjacencies! They will not form otherwise, unless maybe you specify static EIGRP neighbors from hub to spoke, which use unicast instead.

This command tells the spoke who the hub NHRP router is-- in this case GM-R1

The tunnel source is specified as the public interface itself and not the IP- this can be used in case the IP changes dynamically.


I also have a static default route pointing to my ISP router so that clients behind my spoke router can get out to the internet.

What I did here is, deny the private networks in including the tunnel network, from being being natted. I had PAT overloaded the public interface on the spoke routers so that clients can NAT out to the internet, but we obviously don't want the VPN traffic to NAT.

--------------------------------------------------------------------------------------------------------------------------
The other spoke is the same exact thing as the first one....

At this point you should see the peers that have GRE tunnels- as expected, there are 2 tunnels connected to the hub router:

GM-R1#show dmvpn

Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:2,

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 33.33.33.3          192.168.1.3    UP 03:07:36     D
     1 44.44.44.44         192.168.1.4    UP 02:59:23     D


You should have EIGRP neighborships between the hub and each spoke:

GM-R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   192.168.1.4             Tu0                      10 02:10:58  166  1470  0  31
0   192.168.1.3             Tu0                      10 02:14:55  179  1470  0  28

And, if all is well each router should have routes to the other routers networks- and you should be able to ping and pass traffic at this point.

GM-R4#show ip route

Gateway of last resort is 44.44.44.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 44.44.44.254
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D        10.1.1.0/24 [90/26882560] via 192.168.1.1, 02:12:47, Tunnel0
D        10.3.3.0/24 [90/28162560] via 192.168.1.1, 02:00:59, Tunnel0
C        10.4.4.0/24 is directly connected, FastEthernet0/1
L        10.4.4.4/32 is directly connected, FastEthernet0/1
      44.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        44.44.44.0/24 is directly connected, FastEthernet0/0
L        44.44.44.44/32 is directly connected, FastEthernet0/0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, Tunnel0
L        192.168.1.4/32 is directly connected, Tunnel0


Ok......so here's the GETVPN part...utilizing the GDOI protocol running on UDP port 848. The IKE SAs are setup between the group members and the Key Server...communicating over the public internet. Since my key server sits behind R1 on the private network, I had to port forward UDP 848 and IKE 500 and 4500 (when behind NAT, which is my case) on R1- I used a static NAT mapping IP 11.11.11.5 to the private IP of the KS server......

I'll start with the Key Server setup here:

--------------------------------------------------------------------------------------------------------------------------


KS-R5(config)#crypto key generate rsa label VPNKEY1 modulus 1024 exportable


crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
 lifetime 14400
crypto isakmp key getvpn address 0.0.0.0      


crypto ipsec transform-set TRANS1 esp-aes esp-sha-hmac
 mode tunnel
!
crypto ipsec profile IPSEC1
 set transform-set TRANS1


crypto gdoi group GDOI1
 identity number 1
 server local
  rekey algorithm aes 128
  rekey lifetime seconds 14400
  rekey retransmit 15 number 2
  rekey authentication mypubkey rsa VPNKEY1
  rekey transport unicast
  sa ipsec 10
   profile IPSEC1
   match address ipv4 GETVPN-ACL
   replay counter window-size 64
  address ipv4 10.1.1.5

crypto map CRYPTO1 10 gdoi
 set group GDOI1

no ip routing
ip default-gateway 10.1.1.1

ip access-list extended GETVPN-ACL
 deny   udp any eq 848 any eq 848
 permit gre any any

You'll want to create an RSA keypair here, to use for signing the packets.


ISAKMP policy is defined here. I lazily used the 0.0.0.0 (any ip) as the "allowed" addresses for the key usage among the GDOI members. You would want to restrict these to the public facing IP addresses of your member routers- use one line per address.


Your ipsec transform set and encryption types are set here.


Ipsec profile specifying your transform set




The gdoi group settings here. Note the reference to the rsa key generated earlier. You will also match the traffic that is to be encrypted via an ACL....and reference the ipsec profile you just created (IPSEC1)





You actually don't need to enable the crypto map on the interface of the key server since it sits on the private network-but I left it here for reference.


Here, I disabled routing and set the KS's default gateway as if it was just a host unit.

 I denied the gdoi control traffic on udp port  848 here....and permitted GRE tunnel packets, which includes everything running through the DMVPN. This ACL will be downloaded by the member routers too.


--------------------------------------------------------------------------------------------------------------------------

Here's is one of the Group Member routers- R1-you'll do the same for R3 and 4, with the exception of addressing the KS by it's statically natted public IP.

--------------------------------------------------------------------------------------------------------------------------

ip nat inside source list NATISP interface FastEthernet0/0 overload
ip nat inside source static udp 10.1.1.5 500 11.11.11.5 500 extendable
ip nat inside source static udp 10.1.1.5 848 11.11.11.5 848 extendable
ip nat inside source static udp 10.1.1.5 4500 11.11.11.5 4500 extendable

crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
 lifetime 14400
crypto isakmp key getvpn address 10.1.1.5


crypto gdoi group GDOI1
 identity number 1
 server address ipv4 10.1.1.5
!
!
crypto map CRYPTO1 10 gdoi
 set group GDOI1

interface FastEthernet0/0
 ip address 11.11.11.1 255.255.255.0
 ip nat outside
 speed auto
 duplex auto
 crypto map CRYPTO1

With this router- I Natted an additional public IP (11.11.11.5) to the necessary ports on the KS server sitting on the private network.






Isakmp policy here, and, with this router, I referenced the KS server by it's real private IP address- on R3 and 4, you'll use the public natted IP defined above to reach the KS.



GDOI group- basically specifying the KS server- same thing here- use the public natted IP address of the KS on the remote routers- use the real IP here.


Tie it in w the crypto map- CRYPTO1



"Turn on" the Crypto map for the outside public facing interface.


--------------------------------------------------------------------------------------------------------------------------

As soon as you enable the crypto map on the outside interface- the member router should register with the KS, and display the console output similar to below:

GM-R1(config-if)#crypto map CRYPTO1
GM-R1(config-if)#
*Mar 9 22:05:44.991: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.5 for group GDOI1 using address 10.1.1.1
GM-R1(config-if)#
*Mar 9 22:05:45.007: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
GM-R1(config-if)#
*Mar 9 22:06:06.455: %GDOI-5-GM_REKEY_TRANS_2_UNI: Group GDOI1 transitioned to Unicast Rekey.
*Mar 9 22:06:06.459: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Mar 9 22:06:06.475: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Mar 9 22:06:06.583: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.5 complete for group GDOI1 using address 10.1.1.1
*Mar 9 22:06:06.643: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 10.1.1.5 for group GDOI1 & gm identity 10.1.1.1

On the KS server, after configuring the other member routers, you should see Security Associations with each of the 3 member routers, as shown here:

KS-R5#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.1.5        11.11.11.1      GDOI_IDLE         1007 ACTIVE
10.1.1.5        44.44.44.44     GDOI_IDLE         1008 ACTIVE
10.1.1.5        33.33.33.3      GDOI_IDLE         1005 ACTIVE

This will show you group info, number of members, key lifetimes, group ACL etc

KS-R5#show crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI1 (Unicast)
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Group Members            : 3
    IPSec SA Direction       : Both
    Group Rekey Lifetime     : 14400 secs
    Group Rekey
        Remaining Lifetime   : 9195 secs
    Rekey Retransmit Period  : 15 secs
    Rekey Retransmit Attempts: 2
    Group Retransmit
        Remaining Lifetime   : 0 secs

      IPSec SA Number        : 10
      IPSec SA Rekey Lifetime: 3600 secs
      Profile Name           : IPSEC1
      Replay method          : Count Based
      Replay Window Size     : 64
      SA Rekey
         Remaining Lifetime  : 2213 secs
      ACL Configured         : access-list GETVPN-ACL

     Group Server list       : Local

This is the SA from a member router perspective

GM-R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
33.33.33.3      10.1.1.5        GDOI_REKEY        1004 ACTIVE
11.11.11.5      33.33.33.3      GDOI_IDLE         1003 ACTIVE

And again, GDOI info from a group member router- reference the KS via it's public IP

GM-R3#show cry gdoi
GROUP INFORMATION

    Group Name               : GDOI1
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 1
    IPSec SA Direction       : Both

     Group Server list       : 11.11.11.5

    Group member             : 33.33.33.3       vrf: None
       Version               : 1.0.4
       Registration status   : Registered
       Registered with       : 11.11.11.5
       Re-registers in       : 1426 sec
       Succeeded registration: 2
       Attempted registration: 6
       Last rekey from       : 10.1.1.5
       Last rekey seq num    : 6
       Unicast rekey received: 1
       Rekey ACKs sent       : 1
       Rekey Rcvd(hh:mm:ss)  : 01:27:29
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 1
       After latest register : 0
       Rekey Acks sents      : 1

 ACL Downloaded From KS 11.11.11.5:
   access-list   deny udp any port = 848 any port = 848
   access-list   permit gre any any

KEK POLICY:
    Rekey Transport Type     : Unicast
    Lifetime (secs)          : 8521
    Encrypt Algorithm        : AES
    Key Size                 : 128
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024

TEK POLICY for the current KS-Policy ACEs Downloaded:
  FastEthernet0/0:
    IPsec SA:
        spi: 0x4F0F578E(1326405518)
        transform: esp-aes esp-sha-hmac
        sa timing:remaining key lifetime (sec): (1540)
        Anti-Replay : Disabled



At this point, you'll want to send some pings over the network via the tunnel-  the encaps and decaps should increment, confirming that the traffic is indeed being encrypted via GETVPN. 

GM-R3#show crypto ipsec sa

interface: FastEthernet0/0
    Crypto map tag: CRYPTO1, local addr 33.33.33.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   current_peer 0.0.0.0 port 848
     PERMIT, flags={}
    #pkts encaps: 964, #pkts encrypt: 964, #pkts digest: 964
    #pkts decaps: 438, #pkts decrypt: 438, #pkts verify: 438
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 64

     local crypto endpt.: 33.33.33.3, remote crypto endpt.: 0.0.0.0
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0x501F7AB8(1344240312)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x501F7AB8(1344240312)
--------------------------------------------------------------------------------------------------------------------------

So there you have it- 2 cool vpn technologies combined - hope this is helpful and thanks for reading. Also, here's a few excellent references on DMVPN , GETVPN, and IPSEC\IKE\ISAKMP in general.

http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/901-cisco-router-dmvpn-configuration.html

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/getvpn-solution-managed-services/prod_white_paper0900aecd804c363f.html



Also, here are the GNS3 Lab files- downloadable here:

Download Lab








Saturday, October 18, 2014

MPLS3 with GETVPN



Hello all…wanted to share my version of a MPLS lab with you....as if there's not enough MPLS material online! Well, here's one more! The base of the lab was configured with the guidance of Keith Barker, who put up an excellent you tube video on MPLS-check it out here!

I just kind of elaborated on it a bit-added a second customer, a third customer CE, and some GETVPN to get some traffic encryption going. Here’s the config for PE-R2…… at the end of all this, I’ll make my GNS3 lab available for those who want to download it.




version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname PE-R2
!
boot-start-marker
boot-end-marker
!
!
vrf definition dtech
 rd 120:120
 !
 address-family ipv4
  route-target export 20:20
  route-target import 30:30
  route-target import 40:40
  route-target import 137:137
 exit-address-family
!
vrf definition isp
 rd 137:137
 !
 address-family ipv4
  import map DTECH_SELECT
  route-target export 137:137
  route-target import 21:21
  route-target import 31:31
  route-target import 20:20
  route-target import 30:30
  route-target import 40:40
 exit-address-family
!
vrf definition pizza
 rd 121:121
 !
 address-family ipv4
  route-target export 21:21
  route-target import 31:31
  route-target import 137:137
 exit-address-family
!
no aaa new-model
no ip domain lookup
ip domain name lab.local
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.23.2 255.255.255.0
 speed auto
 duplex auto
 mpls ip
!
interface FastEthernet0/1
 ip address 10.0.24.2 255.255.255.0
 speed auto
 duplex auto
 mpls ip
!
interface FastEthernet1/0
 vrf forwarding dtech
 ip address 172.16.12.2 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 vrf forwarding pizza
 ip address 172.16.29.2 255.255.255.0
 speed auto
 duplex auto
!
router ospf 2 vrf pizza
 router-id 0.0.29.29
 redistribute bgp 27 subnets
 network 172.16.29.0 0.0.0.255 area 0
 default-information originate
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.0.0 0.0.255.255 area 0
!
router rip
 !
 address-family ipv4 vrf dtech
  redistribute bgp 27 metric 2
  network 172.16.0.0
  no auto-summary
  version 2
 exit-address-family
!
router bgp 27
 bgp log-neighbor-changes
 neighbor 7.7.7.7 remote-as 27
 neighbor 7.7.7.7 update-source Loopback0
 neighbor 11.11.11.11 remote-as 27
 neighbor 11.11.11.11 update-source Loopback0
 !
 address-family vpnv4
  neighbor 7.7.7.7 activate
  neighbor 7.7.7.7 send-community extended
  neighbor 11.11.11.11 activate
  neighbor 11.11.11.11 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf dtech
  redistribute rip
 exit-address-family
 !
 address-family ipv4 vrf pizza
  redistribute ospf 2
 exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
ip prefix-list DTECH_LOOPS seq 5 permit 1.1.1.1/32
ip prefix-list DTECH_LOOPS seq 10 permit 8.8.8.8/32
ip prefix-list DTECH_LOOPS seq 15 permit 12.12.12.12/32
!
route-map DTECH_SELECT deny 10
 match ip address prefix-list DTECH_LOOPS
!
route-map DTECH_SELECT permit 20










Define your customer VRF and assign a unique Route Distinguisher value in order to keep possible overlapping customer routes unique when traversing MP-BGP.

Define which routes in the customer’s VRF you want to share with other VRFs route-targets. Most times you can just assign the same value for import and export, since you would normally want to share all routes among the same customer vrf, but I just wanted to make them unique for each vrf instance. One for each PE.


For the ISP vrf, I used a route map import so that only select routes were imported in, and other denied. Using the route-target values is all or nothing. Import and export maps will give you more control. In this case, the ISP vrf is importing all other vrf routes, with the exception of dtech, are modified via the import map command. See at the bottom of the config…
























Enable mpls for the interfaces connecting your core routers








This would be your customer facing interface- you’ll want to place this interface in the vrf for your customer. This interface will also exchange routes with the CE’s local routing protocol.


This customer (pizza) uses OSPF as their IGP at the CE. This OSPF instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interface. Note the use of “default-information originate” here. This is necessary to distribute a default route to the CE via OSPF. The route is originated on PE-R7 in the isp vrf, and distributed via MP-BGP like the rest of the routes.

OSPF 1 servers as the core IGP for the MPLS backbone


This customer (dtech) uses RIPv2 as their IGP at the CE. This rip instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interfaces



Here we are defining the BGP pairings for our PE routers that define the MPLS backbone. I did a full mesh between the 3. Also using the loopback0 as the update source instead of the physical interface for redundancy.


It’s here, in the vpnv4 address family, where you are activating the PE BGP neighbors to send vpnv4 customer prefixes which are made globally unique by use of the Route Distinguisher defined earlier. Also, it is the enabling of the extended send-communities in MP-BGP that carry the RD and RT information needed for MPLS vpns to work.



Next, we redistribute the CE’s local IGP into BGP within the respective customer vrfs









Here’s the prefix used in the above import map. I didn't want the isp vrf to have the show dtech loopback networks (lets pretend these were top secret networks). So the loopbacks are defined in the prefix list here, then denied in the DTECH_SELECT route map, effectively preventing them from importation on the to the isp network. Notice the unmatched permit statement at the end of the route map…basically saying “leave everything else as is”

Now, take a look at PE-R7…I’ll go over the differences from PE-R2- it’s all configured the same except for these exceptions.

When your CE’s are using EIGRP as there local routing IGP, you can just create a single EIGRP AS instance on the PE (AS 7 in this case)- then, under your address-family commands, reference the CE’s local EIGRP AS number…. (8, 10, 13 respectively)- then you’ll redistribute BGP into those AS’s so that your customers get the routes.

router eigrp 7
 !
 address-family ipv4 vrf dtech
  redistribute bgp 27 metric 1 1 1 1 1
  network 0.0.0.0
  autonomous-system 8
 exit-address-family
 !
 address-family ipv4 vrf pizza
  redistribute bgp 27 metric 1 1 1 1 1
  network 0.0.0.0
  autonomous-system 10
 exit-address-family
 !
 address-family ipv4 vrf isp
  redistribute bgp 27 metric 1 1 1 1 1
  network 0.0.0.0
  autonomous-system 13
 exit-address-family

Now, there’s a default static route on PE-R7 pointing to the ISP router. I have this route shared among all the vrfs, so that any traffic wo specific routes heads out towards the internet. I distributed this route via the MPLS network to the CEs.

ip route vrf isp 0.0.0.0 0.0.0.0 137.137.137.13

router bgp 27
address-family ipv4 vrf isp
  redistribute static
  default-information originate
 exit-address-family

You’ll want to redistribute static routes into BGP for the isp vrf as shown above- you’ll also need default-information originate so that’s it’s distributed via MP-BGP and shows up in the ipv4 tables for all the vrfs on all the Pes. I’m also peering with the ISP routers local EIGRP as show above on this PE-R7…..other than that, it’s the same as PE-2

The CE routers are just straight peering with their respective IGPs (no redistribution done at the CEs)- advertise the networks you want (I advertised all the CE loopbacks- ie R1 loopback is 1.1.1.1/32) and you should be good to go. You should see the routes for your respective customer offices on the CE (show ip route).

 To check the that you have the correct BGP routes on your PE routers, use show ip bgp all - you'll get a table for each vrf under the VPNv4 address family. (see belowNote the default route in each vrf





Now, you have a functioning MPLS network serving 2 customers! Pretty cool! But….dtech is worried about the security of their traffic between office locations. Pizza doesn’t care- they’re busy making pizzas! So, I’ll implement GETVPN over MPLS to encrypt the interoffice traffic for DTech in the next section. And I'll upload the lab files as well.......  until then....thanks for reading.

Update: 3-2015.............................................................................................................................

Actually....I went through the GETVPN config on another lab.....combining it with DMVPN....so if interested, you can head there and take a look.    http://techjuice.blogspot.com/2015/03/dmvpn-w-getvpn-for-encryption.html

Also, here are the GNS3 Lab files- downloadable here:

Download Lab


Sunday, September 28, 2014

Migrate from Hyper-v VHDX to VMware VMDK on same hardware


I was tasked with migrating VMs from Hyper-V 2012-R2 to VMware's ESXi 5.5 without the luxury of an additional box to install ESXi and just migrate them over with VMware Converter.  So this was an offline tear down\migration of the original Hyper-V server.

I read a few posts about going from vhdx format to vmdk for offline VMs. Seemed easy enough. Use the Hyper-v server's PowerShell to go from vhdx to vhd, like this


Convert-VHD -Path "path to your vhdx" -DestinationPath "path to save your converted vhd"

Then I used Starwinds V2V converter (which you can download for free) to take the vhd to vmdk

http://www.starwindsoftware.com/converter

So I have the vms all set for ESXi, shuffled off and converted- I attach the disks to the newly created machines and get the dreaded 

Failed to start the virtual machine.
Module DevicePowerOn power on failed.
Unable to create virtual SCSI device for scsi0:0, '/vmfs/volumes/50f8922d-eb60e350-2100-6c626d42c9ce/SSD08004.VMAD01.LOCAL__C_Drive-s001.vmdk'
Failed to open disk scsi0:0: Unsupported or invalid disk type 7. Ensure that the disk has been imported



So what to do now? What I should have done to begin with. Download and use the newest version of vCenter Converter Standalone! Just converting to vmdk w starwind is not good enough- there are formatting differences between Workstation, Player and Infrastructure products like ESX and ESXi and must be converted properly.

With my vms installed on the ESXi server but still un-startable, I used Converter to go from 

VMware Infrastructure ------> VMware Player 6.0     (Use "Not pre-allocated" option to keep your disks thin-provisioned if you want)

and then back.....

VMware Workstation or other VMware virtual machine (vmx file)  --->  ESXi host  - same thing, choose "thin provisioned disk" in the destination options if you want

Also, with 2012\Win 8 and above. make sure to boot from EFI and not BIOS--- and I'm back in business!

Another snafu that happens every time, especially with Linux based VMs, is the virtual nic hardware associated with the underlying OS changes, since obviously the nic MAC address changes when the VM is re-imported\moved over to a new system like this. A lot of dependency services (ie Asterisk, etc) refer to the specific nic name in their configs.....and will break if it's changed. So you may have had your OS using eth0 , and now when you move the vm, that nic is apparently gone, and eth1 is active...OR..no nic at all is active when you issue ifconfig at the shell.

You may need to assign an IP to your box to get connectivity - here's the pertinent Linux commands

ifconfig -a                                                                                view all interfaces

ifconfig eth1 up                                                                       enable an interface

ifconifg eth1 192.168.0.xx netmask 255.255.255.0               set static IP

sudo dhclient -v                                                                       view DHCP service info

dhclient -v -r                                                                            release any address from interfaces

dhclient eth1                                                                            enable DHCP on an interface

route add default gw 192.168.x.x eth1                                  add default gateway

route -v                                                                                     show active routes

yum install epel-release                                                          Extra Packages for Enterprise Linux

And the file that maps the MAC to the nic name is found here (at least on CentOS)

“/etc/udev/rules.d/70-persistent-net.rules“

You'll need to take note of your current active nics MAC address, and change the name of the nic to match it- using the previously named nic that worked before (eth0 is this example) Use the dreaded VI editor form the shell, or WinSCP in,... Webmin....whatever you prefer. See the entry example below- there will most likely be 2 entries or more- one for the old nic, and one for the new active one. You can safely delete the old mac entry also...since it's a "tombstoned" device


# PCI device 0×8086:0x100f (e1000)SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”00:50:56:34:0f:38″, ATTR{type}==”1″, KERNEL==”eth*”, NAME=”eth0



So that's it... hopefully this post saves somebody a little aggravation and time!