Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Accessing AWS VPC through an IPSec tunnel, as VPN Client

    Off-Topic & Non-Support Discussion
    2
    7
    880
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      Tikiyetti
      last edited by Tikiyetti

      How do I allow a VPN client access to an AWS VPC subnet?
      I have already configured an IPSec tunnel between my OPT1 network and my AWS VPC. That is working. I can directly ping and ssh EC2s in my VPC.

      But now let's say I VPN into my OPT1 network remotely, and want to use that same IPSec tunnel to ssh to my VPCs like I normally would? Here is what I've been trying so far but I could really use some validation:

      A. Add firewall rule under Firewall > Rules > IPsec with:

      Allow IPv4* AWS * <VPN net> net * *
      Allow IPv4* <VPN net> * <AWS net> net * *

      B. Add firewall rule under Firewall > Rules > OpenVPNwith:

      Allow IPv4* AWS * <VPN net> net * *
      Allow IPv4* <VPN net> * <AWS net> net * *

      C. Add route on client device (Windows) with:

      route ADD <AWS Subnet> MASK 255.255.240. <Gateway IP of TAP interface> IF <Interface ID #>

      D. Add static route on AWS VPN to on-site VPN network

      I am still only able to ping the EC2s if I'm physically on the OPT1 network; and not if I'm VPN'd into it. I have the suspicion it's because I need to add some allow rules between my VPN net and AWS net? Any wizards out there that know what I need to do?

      Thanks,
      ~Klaus

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Create a P2 between the Mobile IPsec tunnel network and the VPC subnet.

        You'll need to add a P2 on the pfSense side and a VPN route on the VPC side.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 1
        • T
          Tikiyetti
          last edited by Tikiyetti

          Ahhh! Of course. Wow. Thank you.
          After adding that, should I also include the VPC as a target subnet for the VPN? The setting under:

          1. VPN > OpenVPN > Servers
          2. Select [VPN] to edit
          3. IPv4 Local network(s)?

          I added it there to test because I still wasn't getting my ping reply, and I know the ICMP traffic is permitted because it works from the OPT1 network. But that didn't help either unfortunately. The next thing I tried was a tracert from an IP inside the VPN network, and an IP inside the OPT1 network. They were identical

          1 <my public ip> 0.269 ms 0.188 ms 0.185 ms
          2 * * *
          3 * * *
          4 * * *
          <snip>
          18 * * *

          I've double checked my route in AWS. It matches the cidr of my VPN 192.168.250.0/24.
          I've tried a ping from PfSense using both OPT1 as the source, and VPN as the source. OPT1 works. VPN doesn't.
          I've triple-checked the P2 configurations. They are identical to my first/original P2 that bridges OPT1 and AWS.

          Sorry to bug you, but do you happen to have any further suggestions?? :P

          Thanks,
          ~Klaus

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Yeah, if you aren't pushing a default route to the VPN clients by checking Redirect Gateway in the server settings. The client has to know to route the destination traffic across the tunnel instead of out WAN.

            Don't add routes to the client.

            Push the routes from the server to the client by adding those networks to Local Networks on the server config.

            I am still only able to ping the EC2s if I'm physically on the OPT1 network; and not if I'm VPN'd into it.

            Unless you did something like a TAP bridge (not recommended) then you are never really VPN'd into the OPt1 network. You have a VPN connection into the same firewall that has the OPT1 network connected to it that you can access.

            You don't need these:

            A. Add firewall rule under Firewall > Rules > IPsec with:

            Allow IPv4* AWS * <VPN net> net * *
            Allow IPv4* <VPN net> * <AWS net> net * *

            B. Add firewall rule under Firewall > Rules > OpenVPNwith:

            Allow IPv4* AWS * <VPN net> net * *
            Allow IPv4* <VPN net> * <AWS net> net * *

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 1
            • T
              Tikiyetti
              last edited by

              Cool, thanks for the correction. That helps my understanding. I've tried both ways: checking Redirect Gateway and explicitly specifying the VPC network, followed by a restart of the service just in case. I'm pretty sure at this point it's a something else in my environment that I don't know, which is conflicting with this.

              Would it be a problem that my VPN traffic uses the VPN gateway (192.168.250.1) that PfSense creates rather than the OPT1 gateway (10.11.12.100)? Or that they're completely different subnets? I wouldn't think different subnets would be unusual since typically the VPN network is supposed to be unique to the network it has access to.

              My desktop physically connected to OPT, trace routes like this:

              tracert 10.99.1.25 (<---EC2 instance ip addr)
              Tracing route to 10.99.1.25 over a maximum of 30 hops
              1 <1 ms <1 ms <1 ms 10.11.12.100
              2 7 ms 6 ms 6 ms 10.99.1.25

              Trace complete.

              But my laptop, connected over VPN trace routes like this:

              tracert 10.99.1.25
              Tracing route to 10.99.1.25 over a maximum of 30 hops
              1 <2 ms <2 ms <2 ms 192.168.250.1
              2 * * * Request Timed Out

              I even tried creating a P2 for another network, like our WiFi to see if it was any different but it's the same behaviour as the VPN network except it uses the gateway of the WiFi network, 192.168.10.1 instead. Should the traffic from these other two networks be getting routed to my OPT1 network first, and then hop to the VPC? Or should they be able to reach the VPC directly from their own gateway like OPT1 by virtue of the P2?

              Thanks,
              ~Klaus

              1 Reply Last reply Reply Quote 0
              • T
                Tikiyetti
                last edited by

                Hey @Derelict just wanted to say thanks for all your help! I am incredibly embarrassed to admit that the issue was that I forgot to allow the VPN network to my AWS security group. :P I think I got config blind and just overlooked the AWS side of the equation. Anyway, still wouldn't have gotten this without your initial help. Thanks again!!

                Thanks,
                ~Klaus

                1 Reply Last reply Reply Quote 1
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  AWS is fun. Glad you got it working.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.