Configure IPsec VPN tunnel to Amazon Web Service VPC

In previous post, I went through the steps to configure IPsec site-to-site VPN connection in AWS VPC. In this post I will go through the steps to configure my local (on-premise) VPN device. These steps are based on the sample configuration provided by Amazon. The instructions here are specific to the Cisco IOS platform I use but the concepts should be common to other devices.

Phase 1 (IKEv1)

First we will configure a matching Phase 1 ISAKMP policy. This will include the standard encryption algorithm, authentication type, hash algorithm, Diffie-Hellman group and lifetime that AWS uses. Note that with Cisco IOS ISAKMP policies are global so they will be used for all connections. I use sequence number 1 here so it will be sent first by the router to negotiate all connections. It can be changed to a higher number if you want to put lower preference to it.

crypto isakmp policy 1
 encryption aes 128
 authentication pre-share
 group 2
 lifetime 28800
 hash sha

The ISAKMP keyring stores the Pre-Shared Key (PSK) used for Phase 1 authentication. The name is typical of what AWS will provide though you can change it if you prefer. It has the public peer IP address of my local VPN device. The PSK is what I had previously configured in AWS.

crypto keyring keyring-vpn-ebf3ee8a-0
 local-address 1.1.1.1
 pre-shared-key address 34.194.43.112 key PRE_SHARED_KEY_1

An ISAKMP profile is then used to associate the keyring with the particular endpoint.

crypto isakmp profile isakmp-vpn-ebf3ee8a-0
 local-address 1.1.1.1
 match identity address 34.194.43.112
 keyring keyring-vpn-ebf3ee8a-0
Phase 2 (IPsec)

Next we configures an IPsec transform set which defines a particular combination of encryption, authentication and IPsec mode parameters. You can name it whatever you want but a sensible and intuitive name is a good idea.

crypto ipsec transform-set ipsec-prop-vpn-ebf3ee8a-0 esp-aes 128 esp-sha-hmac 
 mode tunnel

Next comes the IPSec profile which takes this IPSec transform set and defines further the Diffie-Hellman group and security association lifetime.

crypto ipsec profile ipsec-vpn-ebf3ee8a-0
 set pfs group2
 set security-association lifetime seconds 3600
 set transform-set ipsec-prop-vpn-ebf3ee8a-0

There are several additional IPsec parameters required by Amazon. These parameters are global so if you have existing configurations they may affect your connections.

The configuration below instructs the router to clear the Don’t Fragment (DF) bit from packets that carry it, enabling them to be fragmented. Otherwise those packets maybe dropped if they exceed the maximum frame size.

crypto ipsec df-bit clear

The configuration below enables Dead Peer Detection (DPD) to keep the tunnel up in case it goes idle and there is no traffic flow. It will query the remote peer to check that it is still responding.

crypto isakmp keepalive 10 10 on-demand

The configuration below increases the default value (64 packets) of the gateway’s window for accepting out of order IPsec packets. A larger window can be helpful if too many packets are dropped due to reordering while in transit between gateways.

crypto ipsec security-association replay window-size 128

The configuration below instructs the router to fragment the packets prior to encryption.

crypto ipsec fragmentation before-encryption
Tunnel Interface Configuration

There are two approaches to configuring IPsec site-to-site (also known as LAN-to-LAN / l2l) in Cisco IOS, policy-based and route-based. With policy-based method, we define an ACL – often called a crypto ACL – to identify traffic destined for the VPN tunnel. This crypto ACL is then applied to a real interface, usually the outside, Internet facing, of the router.

With route-based method, we define a logical / virtual tunnel interface (VTI) associated with the IPsec tunnel.  Route-based method is what AWS uses. All traffic routed to this virtual interface will be encrypted and transmitted to our AWS VPC. Conversely, traffic from the VPC will be logically received on this interface.

Association with the IPsec configs (security association) is done through the tunnel protection command. The local and remote addresses on the interface are pre-configured by Amazon and provided in their sample configuration.

interface Tunnel1
 ip address 169.254.46.238 255.255.255.252
 ip virtual-reassembly
 tunnel source 1.1.1.1
 tunnel destination 34.194.43.112 
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile ipsec-vpn-ebf3ee8a-0
 ! This option causes the router to reduce the Maximum Segment Size of
 ! TCP packets to prevent packet fragmentation.
 ip tcp adjust-mss 1379
Static Route Configuration

Finally we need to configure a static route for the prefix corresponding to our VPC to send traffic over the tunnel interface. Here I have used the address range 10.0.0.0/16 for my VPC.

ip route 10.0.0.0 255.255.0.0 Tunnel1 track 1

By default, Amazon configures two tunnels during setup for redundancy and recommends using SLA Monitor to failover between the two tunnels. With the SLA Monitor configured below, the route via Tunnel1 (primary) will be removed if the remote end of the tunnel interface is not reachable (Track 100).

ip sla 1
 icmp-echo 169.254.46.237 source-interface Tunnel1
 timeout 1000
 frequency 5
exit
ip sla schedule 1 life forever start-time now
track 8 ip sla 1 reachability

Second Tunnel

Apart from unique values such as IP address and pre-shared key, the configuration of the second tunnel is identical. I could actually reuse  the IPsec transform set and profile from the first tunnel configuration however for clarity I have configured a separate set per the sample config from Amazon.

crypto keyring keyring-vpn-ebf3ee8a-1
 local-address 1.1.1.1
 pre-shared-key address 34.197.154.29 key H57dlSoEZY5g8gUmeCrRrxerdiIw8gCy
!
crypto isakmp profile isakmp-vpn-ebf3ee8a-1
 local-address 1.1.1.1
 match identity address 34.197.154.29
 keyring keyring-vpn-ebf3ee8a-1
!
crypto ipsec transform-set ipsec-prop-vpn-ebf3ee8a-1 esp-aes 128 esp-sha-hmac 
 mode tunnel
!
crypto ipsec profile ipsec-vpn-ebf3ee8a-1
 set pfs group2
 set security-association lifetime seconds 3600
 set transform-set ipsec-prop-vpn-ebf3ee8a-1
!
interface Tunnel2
 ip address 169.254.46.30 255.255.255.252
 ip virtual-reassembly
 tunnel source 1.1.1.1
 tunnel destination 34.197.154.29 
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile ipsec-vpn-ebf3ee8a-1
 ip tcp adjust-mss 1379 
!
ip route 10.0.0.0 255.255.0.0 Tunnel2 track 10
!
ip sla 2
 icmp-echo 169.254.46.29 source-interface Tunnel2
 timeout 1000
 frequency 5
!
ip sla schedule 2 life forever start-time now
track 10 ip sla 2 reachability

 

Configure VPN connection in AWS VPC

This is a quick guide on how to configure IPsec site-to-site VPN connection from your local network to AWS VPC. We are going through the steps required on AWS side.

From the AWS Console, go to the VPC section and click on Virtual Private Gateways under VPN Connections. From there, click on Create Virtual Private Gateway. Give it an appropriate name.

Amazon will assign a unique ID to the Virtual Private Gateway (VPG) you just created.

The next step is to create a VPN Connection and attach it to this VPG. Give it an appropriate name and select the VPG you just created. Select New for Customer Gateway and enter the outside/external IP Address of your on-site VPN device. For this example we will use static routing so leave BGP ASN with the default value (65000) and select Static as Routing Options. In Static IP Prefixes, enter the address range of your local network. Leave the fields under Tunnel Options blank. Amazon will automatically generate them.

Once you have created the VPN Connection, there will be an option to Download Configuration for devices supported by AWS. You will need this to configure your VPN device.

Using the provided configuration, configure your local VPN device. When completed, you can confirm if the tunnels are up by clicking on the Tunnel Details tab.

If you can’t establish connectivity between your local hosts and the hosts in your VPC, check that routes from the VPG are propagated to your VPC. Go to Route Tables, select the Routes tab and check the routes.

If the route to your local network is not listed, click on the Route Propagation tab and ensure that the Virtual Private Gateway is enabled to Propagate.

Once everything have been configured properly, you should be able to ping from your local network to your VPC and vice-versa. Make sure to delete the VPN Connection from your AWS VPC when you are no longer using it otherwise Amazon will continue charging for it.

MacBook Pro runs very slow when on battery

A colleague gave me a 2010 MacBook Pro and I notice that it runs very slow when running on battery. Boot-up takes a very long time and everything is lagging. It is practically unusable. When the power supply is plugged in however, it works normally. I tried the usual prescribed troubleshooting from Apple to reset the SMC but that still didn’t fix the issue.

Finally I came across this discussion on Apple Support Communities. The root cause seems to be faulty temperature sensor damaged by liquid spill. Because the sensor is faulty, macOS assumes the system is overheating and drops the CPU cycle which in turns makes everything runs much slower.

To check if your Mac has the same issue, quit all programs and with the power supply connected, open Activity Monitor and click on the CPU tab. Check the usage percentage at the bottom. It should be minimal at around 1%. Now disconnect the power supply and see if the figure spikes up to around 80%.

Short of getting your logic board repaired, the workaround is to disable this feature by removing a system file. Keep in mind though that doing this effectively disable CPU throttling and will reduce battery life.

First, identify the model of your Mac by clicking on the Apple on the top menu bar and select About this Mac. From the About this Mac pane click on System Report…. Select Hardware in the left panel and make a note of the Model Identifier. For mine it was MacBookPro7,1.

If you’re running El Capitan or higher, we first need to turn off System Integrity Protection (SIP). Follow these steps to turn SIP off.

  • Restart your Mac.
  • While it is booting hold down Command-R to boot into the Recovery System.
  • Click on Utilities from the menu bar and select Terminal.
  • Type csrutil disable and press return.
  • Close the Terminal app.
  • Restart your Mac.

Now with SIP turned off, open a Finder window and click on Macintosh HD.

  • Click on System > Library > Extensions.
  • Locate the file called IOPlatformPluginFamily.kext, right-click on it and select Show Package Contents.
  • Click on Contents > PlugIns.
  • Locate the file called ACPI_SMC_PlatformPlugin.kext, right-click on it and select Show Package Contents.
  • Click on Contents > Resources.
  • Find the the plist file that corresponds to your Model Identifier. In my case it is MacBookPro7_1.plist.
  • Move it to Trash.
  • Restart.

Your Mac should run normally when on battery now. Lastly, you might want to turn SIP back on by following the same steps as above but typing csrutil enable this time.

Setup port channel between a pair of Cisco ASA and a switch stack

For better redundancy, we may want to use port channel to connect a high availability active/passive pair of Cisco ASA to a switch stack. An important aspect to know is to create separate port channels on the switch stack, one for each ASA. On each ASA, it is still a single port channel because the configuration is replicated between the units. If you group all interfaces on the switch stack into a single port channel connecting to both ASA, the port channel will not be established because of the separate ASA system IDs. A single port channel is also not desirable because you do not want traffic to be sent to the standby ASA.

The following diagram from this Cisco document explains it all.

Following this diagram, we configure two port-channels on the switch stack.

!
interface Port-channel2
switchport mode trunk
!
interface Port-channel3
switchport mode trunk
!

We then apply the port channel configuration to the four switch interfaces which are connected to the ASA pair.

!
interface GigabitEthernet3/2
description to ASA-Primary
switchport mode trunk
channel-group 2 mode active
!
interface GigabitEthernet6/2
description to ASA-Primary
switchport mode trunk
channel-group 2 mode active
!
interface GigabitEthernet3/3
description to ASA-Secondary
switchport mode trunk
channel-group 3 mode active
!
interface GigabitEthernet6/3
description to ASA-Secondary
switchport mode trunk
channel-group 1 mode active
!

Let’s now configure port-channel on the ASA pair.

!
interface Port-channel1
no nameif
no security-level
no ip address
!

We then apply the port-channel to the two interfaces on each ASA.

!
interface GigabitEthernet0/0
channel-group 1 mode active
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/1
channel-group 1 mode active
no nameif
no security-level
no ip address
!

The next step is important; for each VLAN we create a subinterface on the port channel. In each, we define the VLAN ID, IP address and security-level. In the example below we create:

!
interface Port-channel1.10
vlan 10
nameif INSIDE
security-level 100
ip address 10.1.1.2 255.255.255.0
!
interface Port-channel1.1000
vlan 1000
nameif OUTSIDE
security-level 0
ip address dhcp setroute
!

It is important to have the same VLAN ID of both side. When adding a new VLAN apply the configuration on the switch stack first.

Cisco ASA – A group cannot contain services of different types

In Cisco ASA 6.4.9 – and older possibly – it is possible to mix different types of service in a group. So you can have TCP and UDP or TCP-UDP and TCP in the same group.

Later versions of ASA do not allow this. In ASDM, you will get error message like below if you attempt to do this.

Additionally, if you had created a group with mixed types of service, later version of ASDM will not show this service group.

Reference Frame Implementation in CORS Network and RTK Service

With the recent discussions on a new Australian datum (GDA2020), I have come across several queries regarding datum implementation in CORS network system and RTK service.

The basic principle to keep in mind is that RTK, or more descriptively, carrier-phase double-differencing, is a relative positioning technique. Unlike DGPS or PPP, it does not solve directly for coordinate but instead compute the vector (baseline) between the reference point (base station or CORS) and the unknown point. This vector is then applied to the known, accurately surveyed coordinate of the reference point to produce the coordinate of the unknown point (see Hofmann-Wellenhof, Lichtenegger, Collins, GPS Theory & Practice, Section 8.3 for further details).

For an RTK service, the measurements (or observables) made at the reference station are transmitted to the rover receiver occupying the unknown point. The rover uses the observables from the reference station along with its own observables to compute the vector between the reference station and itself. Known accurate coordinate of the reference station is also sent in the transmission stream which the rover then uses to compute its own accurate coordinate.

So what happens when CORS network operators switch from GDA94 to GDA2020? Quite simply, the reference coordinate sent in the stream will change. And that’s about it. The observables remain the same. The computed vector remains the same. But because the reference coordinate has changed, the computed coordinate at the rover will change too.

So if my service provider offers parallel streams, one in GDA94 and another in GDA2020, can I tell which is which?

It depends. Out-of-band, the operator can always provide relevant metadata about the streams – including reference frame – through various mechanisms. It can be specified on their website or reflected in the stream’s name (for example, Bathurst-RTCM3-GDA2020).

In-band – that is, from the content of the stream itself – it depends on the message format used. Let’s look at RTCM 3 which is the most widely used international standard for CORS network and RTK service. The RTCM standard specifies the reference coordinates in Earth-Centre-Earth-Fixed (ECEF) coordinates with the option to specify their ITRF realisation year. This implies that the reference frame is ITRF but regional CORS network operators often use their local datums directly. For example, in Australia, CORSnet-NSW and GPSnet currently transmit GDA94 coordinate in their RTCM streams. Anyone using their RTK services will produce coordinates in GDA94 which is the intended purpose.

When the operators migrate to GDA2020, the GDA94 coordinates will be replaced with GDA2020 coordinates and the X, Y, Z values transmitted in the RTCM stream will change. Additionally, an operator may choose to keep the current stream (and GDA94 coordinate) and create a new ‘GDA2020 stream’ with a different set of coordinate values transmitted. The observables for these streams are identical, only their coordinate values differ.

Alternatively, an operator could employ a strict implementation of the RTCM standard and transmit the reference coordinate in ITRF. RTCM supports the transmission of transformation parameters which can then be used by the rover to automatically transform the computed coordinate from ITRF to the desired datum. This will require network operators to include the appropriate Coordinate Transformation Messages in their streams.

As of Version 3.2, the RTCM standard is yet to support dynamic datum however this support is planned in the future.

Leap Second 2015 and GNSS

It looks like some GNSS receiver decides to implement leap second a day early.

RTCM3 (2015-06-30T05:02:55.05) Type 1013 (size 9): ID= 165, MJD=57203, SOD=18173, Num= 0, Leap=17

BeiDou, China’s own GPS

While the United States’ GPS is used in pretty much all vehicle navigation systems and smartphones, and Russia’s GLONASS is making inroads, not many are aware that China has been busy launching its own global navigation satellite system called BeiDou. Over the past three years or so, China has significantly expanded BeiDou and there are now more than 10 BeiDou satellites orbiting. Continue reading

RTKLIB on Raspberry Pi

High accuracy GNSS positioning has always been associated with expensive commercial solutions. So I was pretty thrilled when I first heard about RTKLIB. Developed for the past seven years by Tomoji Takasu, RTKLIB is a free open source software for GNSS data processing. It has an impressive list of features, decoding of multiple formats (including the latest RTCM 3.2), NTRIP support, multiple constellations support, post processing and real-time processing ranging from single point positioning to RTK to PPP.

A great thing about RTKLIB is that it is highly portable. It is written in standard C and can be compiled on many different operating systems and platforms, including the hugely popular Raspberry Pi. Run the free RTKLIB on a fifty bucks Raspberry Pi connected to a low cost GNSS board (such as the u-blox LEA-xT series), now you have access to centimetre level positioning without the thousands of dollars price tag. Continue reading

GNSS Constellation Status from UNB

If you ever need to check, the University of New Brunswick keeps a nice tally of all the GPS and GLONASS satellites, when they were launched and decommissioned. Here’s the links for GPS and GLONASS.