DIY Sysadmin

Enterprise. At home.

Tag: IPsec

  • IPsec between Sophos and pfSense.

    One of the vendors that I’ve seen in small and medium businesses was Sophos. So, we can conclude that Sophos is Enterprise. Lucky for us, we can run the Sophos Firewall at home, thanks to their Sophos Home Edition Firewall. “Enterprise. At home”, remember? It is the same firewall you’d get from Sophos but with a few limitations1:

    • CPU is limited to 4 cores.
    • RAM is limited 6 GB.

    The machine can have more resources than that but Sophos will use up to that limit. I think it’s fair enough. I’ll be virtualizing our Sophos Home Edition Firewall and will provide the resources it needs. Note, the installer requires 4 GB of RAM minimum and 32 GB of disk. It complains otherwise. Also, by default, Sophos’s Port 1 is LAN and Port 2 is WAN. Your first vNIC will be LAN and your second vNIC will be WAN. Keep this in mind when you connect your topology. By default, Port 1 is running a DHCP server with 172.16.16.0/24 subnet, and the default address for the firewall configuration is 172.16.16.16:4444.

    Here’s the topology I’m using for this demonstration.

    Topology
    Figure 1. Topology.
    • All subnets are /24 for simplicity, unless noted otherwise.
    • R0 is a pfSense instance that simulates WAN. It is connected to the internet. It runs DHCP servers for the downstream routers. The subnets are 10.0.111.0/24 on the left and 10.0.222.0/24 on the right.
    • PFSENSE and SOPHOS are the firewalls/routers that we’ll be connecting via site-to-site IPsec tunnel.
    • PC1 and PC2 are our end devices. We’ll use PC1 to manage PFSENSE and PC2 to manage SOPHOS.

    Sophos

    I’m not going to bore you with the initial Sophos setup. I am confident that you can run through the wizard.

    Sophos is a Zone based firewall. It is pretty intuitive and user-friendly but I did encounter a couple of “gotchas” setting IPsec up. And the first one is that we need to enable IPsec access on the WAN zone. On the right hand side pane, click on “Administration” under the “System” heading. Then go to “Device access”, check the IPSec for WAN zone and click “Apply”.

    Figure 2. Administration -> Device access -> Enable IPsec on WAN.
    Figure 2. Administration -> Device access -> Enable IPsec on WAN.

    Another gotcha is that there seems to be some “miscommunication” between pfSense and Sophos when they negotiate IPsec Phase 1. If pfSense has pretty restrictive settings (I use the same settings as in my Meraki example) and Sophos has multiple settings (even if there would be a matching combination) and if Sophos is the initiator, pfSense and Sophos cannot agree on the communication parameters and can’t establish a tunnel. If pfSense is the initiator, the tunnel is established. But to work around it, I’d recommend creating an IPsec profile that matches the pfSense parameters exactly. This way there’s no “miscommunication”.

    Go to “Profiles” under “System” on the right. Then to “IPsec profiles” and click “Add”.

    Figure 3. Profiles -> IPsec profiles.
    Figure 3. Profiles -> IPsec profiles.

    There create a new IPsec profile. I used the following settings:

    • “Name”: “pfsense_test”.
    • “Key exchange”: “IKEv2”.
    • “Authentication mode”: “Main mode”.
    • Phase 1 “Key life”: “28800:
    • Phase 1 “DH group (key group)”: “21 (ecp521)”.
    • Phase 1 “Encryption”: “AES256”.
    • Phase 1 “Authentication”: “SHA2 256”.
    • Phase 2 “DH group (key group)”: “21 (ecp521)”.
    • Phase 2 “Key life”: “3600”.
    • Phase 2 “Encryption”: “AES256”.
    • Phase 2 “Authentication”: “SHA2 256”.
    Figure 4. IPsec profile.
    Figure 4. IPsec profile.
    Figure 5. IPsec profile, continued. Phase 1 and Phase 2.
    Figure 5. IPsec profile, continued. Phase 1 and Phase 2.

    Now let’s go to “Site-to-site VPN” under the “Configure” section on the left and create a new IPsec tunnel. I used the following settings:

    • “Name”: “pfsense_test”.
    • “IP version”: “IPv4”.
    • “Connection type”: “Policy-based”.
    • “Profile” under “Encryption”: “pfsense_test”. This is the profile we created in the steps above.
    • “Authentication type”: “Preshared key”.
    • “Preshared key”: your super secret password.
    • “Local gateway” is the section where we configure the local side of the VPN tunnel. “Listening interface”: “Port 2 – 10.0.222.251”. This is your WAN interface on Sophos with its “public” WAN IP. Since we’re using it in a lab the IP in 10.0.222.0/24 range, R0’s R0R2 interface on the right side of the topology.
    • “Local ID type”: “IP address” and “Local ID”: “10.222.251”. This can be arbitrary but we’ll use these settings to identify the IPsec peers, so make it make sense to you. I just use the WAN IP address.
    • “Local subnet”: create a new subnet as in Figure 8. We’ll be advertising the local 172.16.16.0/24 subnet to the remote peer. But you can create as many entries there as needed.
    • “Remote gateway” is the pfSense side of the tunnel. In the “Gateway address” we put the public IP address of the pfSense (FQDN works too), in our case it’s 10.0.111.111. Again, refer to the topology above.
    • “Remote ID type”: “IP address”.
    • “Remote ID”: “10.0.111.111”.
    • Create a “Remote subnet” as in Figure 9. The subnet we use is 10.111.111.0/24, the LAN subnet off pfSense’s R0R1 interface.
    Figure 6. Site-to-site VPN configuration.
    Figure 6. Site-to-site VPN configuration.
    Figure 7. Site-to-site VPN configuration, continued. Gateway settings.
    Figure 7. Site-to-site VPN configuration, continued. Gateway settings.
    Figure 8. Creating local subnet.
    Figure 8. Creating local subnet.
    Figure 9. Creating remote subnet.
    Figure 9. Creating remote subnet.

    After saving, we can enable and activate our tunnel. Did you think we were done? No way! We need to create the firewall rules to allow the traffic between the subnets across the tunnel. Head to “Rules and policies” under the “Protect” section. There we’ll create 2 firewall rules: allowing LAN to VPN and allowing VPN to LAN. Essentially, you’ll select “VPN” as the source zone and “LAN” as destination to allow traffic from the VPN tunnel to the LAN. Make sure to select “Accept” as the “Action”. Switch “LAN” and “VPN” around to allow LAN traffic through the tunnel.

    Figure 10. Firewall rules.
    Figure 10. Firewall rules.
    Figure 11. Creating Firewall rule allowing VPN in.
    Figure 11. Creating Firewall rule allowing VPN in.
    Figure 12. Creating Firewall rule allowing VPN in, continued.
    Figure 12. Creating Firewall rule allowing VPN in, continued.
    Figure 13. Creating Firewall rule allowing LAN out.
    Figure 13. Creating Firewall rule allowing LAN out.

    OK. We’re done with Sophos. I promise. But we’re only half way done with the tunnel. Time to configure the pfSense side.

    pfSense

    The pfSense configuration will be very similar to what we did when we setup a tunnel with Meraki. So I may omit some details.

    As always we start with creating Phase 1 and Phase 2 settings for the IPsec tunnel. Head to VPN -> IPsec. Here are the settings I used:

    • “Description”: “sophos”.
    • “Key Exchange version”: “IKEv2”.
    • “Internet Protocol”: “IPv4”.
    • “Interface”: “WAN”. This is the interface that is connected to “internet”.
    • “Remote Gateway”: “10.0.222.251”, the “public” IP address of Sophos. FQDN also works.
    • For “Phase 1 Proposal (Authentication)”, “Authentication Method”: “Mutual PSK”.
    • “My Identifier”: “IP address” and “10.0.111.111”. Make sure this matches the “Remote ID” set up in the Sophos IPsec configuration.
    • “Peer Identifier”: “IP address” and “10.0.222.251”. Make sure this matches the “Local ID” set up in the Sophos IPsec configuration.
    • “Pre-Shared Key”: use your super secret password that you put into the Sophos configuration. Do NOT use “test123”, it’s bad!
    • For “Phase 1 Proposal (Encryption Algorithm)”, “Encryption Algorithm”: “AES” for “Algorithm”, “256 bits” for “Key length”, “SHA256” for “Hash”, and “21 (nist eco 521)” for “DH Group”.
    • Put “Life Time”: “28800”.
    Figure 14. IPSec Phase 1.
    Figure 14. IPSec Phase 1.
    Figure 15. IPSec Phase 1, continued.
    Figure 15. IPSec Phase 1, continued.

    For Phase 2, I used the following settings:

    • “Description”: “sophos”.
    • “Mode”: “Tunnel IPv4”.
    • “Local Network”: “R0R1 subnet”. Make sure that the subnet on the pfSense is the same as configured in the Sophos configuration for “Remote subnet”.
    • “Remote network”: “172.16.16.0/24”, the same network as “Local subnet” in the Sophos IPsec configuration.
    • For the “Phase 2 Proposal (SA/Key Exchange)”: “Protocol”: “ESP”. This will ensure that the traffic is encrypted.
    • “Encryption Algorithms”: “AES”, “256 bits”.
    • “Hash Algorithms”: “SHA256”.
    • “PFS key group”: “21 (nist ecp521)”.
    • “Life Time”: “3600”.
    Figure 16. IPsec Phase 2.
    Figure 16. IPsec Phase 2.
    Figure 17. IPsec Phase 2, continued.
    Figure 17. IPsec Phase 2, continued.

    Now, we need to configure the inbound firewall rules. Head to Firewall -> Rules -> WAN. Create two rules: one allowing UDP from “10.0.222.251” (Sophos “public” IP) to “WAN address”, port “500 (ISAKMP)”, and one for ESP from “10.0.222.251” to “WAN address”. If you’re behind a NAT, then you’ll need to create a rule allowing UDP port 4500 (NAT-T). Make sure you create appropriate rules to allow traffic between the subnets behind the VPN. The interface group is called “IPsec” in the Firewall -> Rules section.

    Figure 18. pfSense WAN firewall rules.
    Figure 18. pfSense WAN firewall rules.

    After all of that we can see that our tunnel is established. Head to Status -> IPsec to confirm.

    Figure 19. pfSense IPsec status.
    Figure 19. pfSense IPsec status.

    We can also confirm that the tunnel allows traffic by pinging from PC1 to PC2 and vice-versa.

    Figure 20. Ping from PC2 (172.16.16.17) to PC1 (10.111.111.2).
    Figure 20. Ping from PC2 (172.16.16.17) to PC1 (10.111.111.2).

    And this is it. Just like with the Meraki security appliance, the set up is simple just tedious. There were a couple of gotchas: allow VPN access on WAN and create an IPsec profile. But that’s the price of running enterprise at home…

    1. https://www.sophos.com/en-us/free-tools/sophos-xg-firewall-home-edition ↩︎

  • IPsec between Meraki and pfSense.

    Over the weekend, I visited my other location and set a Meraki Z4 up. This also allowed me an opportunity to configure a Site-to-Site IPsec VPN tunnel between this location and my main location that’s running a pfSense appliance. This tunnel will be used for off-site backup transfers.

    The process of setting up the site-to-site IPsec tunnel is fairly straightforward. I think it took me five times as long to write this post than to actually get it running. We’re going to start with the Meraki side and then will shift gears to pfSense. There will be information that we need to share between the two devices during the set up. So, let’s get going.

    Meraki

    First, go to your Meraki Dashboard network and click Security Appliance (or, in my case, Teleworker gateway) -> Configure -> Site-to-site VPN.

    FIgure 1. Security Appliance (or Teleworker gateway) -> Configure -> Site-to-site VPN.
    FIgure 1. Security Appliance (or Teleworker gateway) -> Configure -> Site-to-site VPN.

    There, scroll about half way, and, under the “IPsec VPN peers” section, click “+ Add a peer”.

    Figure 2. Add a IPsec VPN Peer.
    Figure 2. Add a IPsec VPN Peer.

    In the new opened pane:

    • Type in a “Name”. This name will be used to identify the peer, so choose the name that would make sense to you.
    • Select “IKE version” IKEv2 (it allows a bit more options compared to IKEv1).
    • In the “Public IP or Hostname” use the IP or the hostname of your remote site. In my case, I am using the fully qualified domain name of my pfSense site. Note, that FQDN peering requires MX (or Z) appliance firmware of 18.1 or higher.
    • Type in a “Local ID”. I prefer to use a private IP that is not used in my environment.
    • Type in a “Remote ID”. I use the same approach as with the Local ID.
    • Next, type in “Shared secret”. This secret will also be used on our pfSense appliance, so make sure you copy it somewhere. Use a strong randomly generated key. You won’t need to type it in so the more complex the better.
    Figure 3. Creating a Peer.
    Figure 3. Creating a Peer.

    Scrolling down, select:

    • “Static” under “Routing”.
    • In the “Private subnets”, include the subnets the remote peer (pfSense, in my case) will be advertising to this location.
    • “Availability” – select the network this IPsec peer should be peering with.
    • Select options for “Tunnel monitoring”. I am not using anything at the moment, but it does require a Health check option to be set up.
    • Keep “Failover directly to internet disabled”. We’re only tunneling local subnets so this option is irrelevant to us.
    Figure 4. Creating a Peer, routing.
    Figure 4. Creating a Peer, routing.

    Now, in the “IPsec policy”, select “Preset” “Secure”. It has the highest settings that the Meraki security appliance currently supports and it makes setup easier. The settings for Phase 1 and Phase 2 are below. Take a note, as we’ll need to use the same setting on our remote pfSense peer. When done click “Save” and then “Save Changes” button at the bottom of the page.

    Figure 5. Creating a Peer, Phase 1.
    Figure 5. Creating a Peer, Phase 1.
    Figure 6. Creating a Peer, Phase 2.
    Figure 6. Creating a Peer, Phase 2.

    At the bottom of the Site-to-site VPN page you can set the Site-to-site outbound firewall rules. These rules apply to traffic going across the IPsec tunnel. By default, Meraki uses Allow Any. I prefer to allow only what I need and also Deny Any right above the Allow Any “Default rule”.

    Figure 7. Site-to-site firewall rules.
    Figure 7. Site-to-site firewall rules.

    We’re pretty much done with the Meraki side. But, since this tunnel is between two residential locations, we have a dynamic public DNS. Previously, I described how I manage the dynamic public IPs with DynDNS. Meraki makes it super easy as it manages the DynDNS records by default. Go to Security appliance (Teleworker gateway) -> Appliance status. There copy the “Hostname” (ending with .dynamic-m[.]com). We’ll use it when we set up pfSense.

    Figure 8. Appliance Status.
    Figure 8. Appliance Status.

    pfSense

    By default, Meraki denies any incoming traffic. When you create an IPsec tunnel, it allows it through the firewall automatically. pfSense does the same. I’m not a dan of it as I’d like more control over my firewall rules. So the first thing we’ll do is go to System -> Advanced -> Firewall & NAT. About half way through you’ll see the “Advanced Options” section. In this section check “Disable all auto-added VPN rule” and click “Save” at the very bottom of the page.

    Figure 9. System -> Advanced -> Firewall & NAT.
    Figure 9. System -> Advanced -> Firewall & NAT.

    Now go to VPN -> IPsec. There click the “+ Add P1” green button. There:

    • Enter the “Description”. This is only for administrative purposes so choose something that would make sense to you.
    • Select “Key Exchange version” “IKEv2”.
    • In “Interface”, select the interface that is connected to the internet. It is “GATEWAY” in my example.
    • In the “Remote Gateway” type in the fully qualified domain name for your Meraki appliance. We copied it from the Appliance status page, it ends with .dynamic-m[.]com.
    Figure 10. IPsec Phase 1.
    Figure 10. IPsec Phase 1.
    • For the “Phase 1 Proposal (Authentication)” select “Mutual PSK” for the “Authentication Method”.
    • For “My identifier” and “Peer identifier” use the same IP addresses you used on the Meraki side (the Meraki identifier is the “Peer identifier” in this case).
    • Paste the super secret and complex key you used on the Meraki appliance into the “Pre-Shared Key” field.
    • For the “Phase 1 Proposal (Encryption Algorithm), we need to use the same settings as on our Meraki appliance.
    • Use “AES” for “Algorithm”.
    • Use “256 bits” for “Key length”.
    • Use “SHA256” for “Hash”.
    • Use “21 (nist ecp521)” for “DH group”.
    • Select “Life Time” of “28800”.
    Figure 11. IPsec Phase 1, continued.
    Figure 11. IPsec Phase 1, continued.

    In the “Advanced Options” select “None (Responder Only)” for “Child SA Start Action”. This forces the Meraki device to initiate the tunnel. You can leave everything else at default. Click the blue “

    Figure 12. IPsec Phase 1, continued.
    Figure 12. IPsec Phase 1, continued.

    Now, in the “VPN / IPsec / Tunnels” expand the item we’ve just created by clicking on the “Show Phase 2 Entries” button and then click the green “+ Add P2” button. There:

    • Enter a description.
    • Select “Tunnel IPv4” for the “Mode”. This is the mode we’ll use for the static routing through our IPsec tunnel.
    • Under “Networks” subsection, for “Local Network” select “Network” for the “Type” and enter the IP sunset that the pfSense appliance will be sharing through the tunnel.
    • Do the same thing for the “Remote Network” but enter the IP subnet that the Meraki device will be sharing.
    Figure 13. IPsec Phase 2.
    Figure 13. IPsec Phase 2.

    In the “Phase 2 Proposal (SA/Key Exchange)”, enter:

    • “ESP” for “Protocol”. This is what enables encryption of the IPsec tunnel.
    • “AES” and “256 bits” for “Encryption Algorithms”.
    • “SHA256” for “Hash Algorithms”.
    • “21 (nist ecp521)” for “PFS key group”.
    • Under the “Expiration and Replacement” select “14400” for “Life Time”. And then click the blue “Save” button.
    Figure 14. IPsec Phase 2, continued.
    Figure 14. IPsec Phase 2, continued.

    OK. We’re done with the tunnel set up. It should look something like this:

    Figure 15. pfSense IPsec Tunnels.
    Figure 15. pfSense IPsec Tunnels.

    But our VPN tunnel will not be established, because we disable all auto-added VPN rules. So let’s change that. Go to Firewall -> Aliases -> IP and click the green “+ Add” button. Here we’ll create an alias for our Meraki device. Aliases in pfSense act sort of like groups. We can put multiple items into an alias and then create a firewall rule using it. If we need to make any changes, we can edit alias and those changes will propagate into the firewall rules. For this alias:

    • Create a name following the requirements. We will use this name when we create our firewall rules.
    • Enter a description.
    • For “Type” select “Host(s)”.
    • For “IP or FQDN” enter the fully qualified domain name for the Meraki appliance that we copied from Appliance status page from the Meraki Dashboard.
    • Type in a description that will make sense to you if you need to figure out what you did six months down the road.
    • Click the blue “Save” button.
    Figure 16. pfSense Firewall Aliases.
    Figure 16. pfSense Firewall Aliases.

    Now, go to Firewall -> Rules -> GATEWAY (or whatever your internet connected interface is called). There create 2 rules: one for ISAKMP and another for NAT-T. The screenshots are below, but:

    • Select “Action” “Pass”.
    • For “Interface” select “GATEWAY” (your internet connected interface).
    • “Address Family” “IPv4”.
    • “Protocol” “UDP” (as IPsec uses UDP for ISAKMP and NAT-T).
    • Select “Address or Alias” under “Source”. Start typing the alias name we created and it should auto-populate with the name.
    • In the “Destination” select “GATEWAY address”, where “GATEWAY” is your internet connected interface.
    • Click the blue “Display Advanced” button in the “Destination” section.
    • Select “ISAKMP (500)” for both “From” and “To” port ranges under “Destination Port Range”
    • Enter a description and click “Save”.
    • Repeat, but select “IPsec NAT-T (4500)” for the “Destination Port Range” to create a rule allowing NAT-T.
    • Save and click “Apply Changes”.
    Figure 17. pfSense firewall rules, ISAKMP.
    Figure 17. pfSense firewall rules, ISAKMP.
    Figure 18. pfSense firewall rules, NAT-T.
    Figure 18. pfSense firewall rules, NAT-T.

    Alright. Our tunnel should form now. But no traffic will flow through. It is because, unlike Meraki, pfSense denies the IPsec tunnel traffic by default. Let’s create rule allowing in. Go to Firewall -> Rules -> IPsec and create a new rule as follows:

    • “Action” – “Pass”.
    • “Interface” – “IPsec”.
    • “Address Family” – “IPv4”.
    • “Protocol” – “Any”.
    • “Source” – Meraki IP subnet, in our example it is “10.16.23.0/24”.
    • “Destination” – the subnet on pfSense that we’re setting up tunnel for, in this example “172.16.23.0/24”.
    • Enter the description, save, and apply changes.
    Figure 19. pfSense firewall rules.
    Figure 19. pfSense firewall rules.

    Now we should be good. On pfSense go to Status -> IPsec to confirm that the tunnel is up and running. To do the same in the Meraki Dashboard, go to Security Appliance (Teleworker gateway) -> VPN Status -> 1 IPsec peer. It should have a green circle next to the tunnel name.

    Figure 20. pfSense IPsec tunnel status.
    Figure 20. pfSense IPsec tunnel status.
    Figure 21. Meraki IPsec tunnel status.
    Figure 21. Meraki IPsec tunnel status.

    This is it. Not too complicated. Just need to make sure that the parameter match between the peers, that proper IP subnets are advertised, and that the firewall rules allow communication. If the tunnel is not being established, take packet captures on the WAN interfaces of the Meraki and the pfSense appliances. Look for unidirectional traffic and troubleshoot from there. But that is a different post…