[SOLVED] VPN Tunnel



  • Hello

    We have IKEv2 VPN setup with pfSense and this works fine. (Office servers can ping VPN user, VPN users can ping office servers)
    We also have a VPN tunnel setup on pfSense to AWS using a VPC VPN and this all works fine (AWS servers can ping office servers, office servers and ping AWS servers)

    Here is the BUT…. IKEv2 users cannot ping AWS servers and AWS servers cannot ping IKEv2 users.

    See attachment for network layout.

    Can anyone help me with this?



  • I am still looking into this.
    Any help you be great



  • Have you two Phase 2 entries? BTW, some IPSEC systems can have only one Phase 2 entry.



  • @yarick123:

    Have you two Phase 2 entries? BTW, some IPSEC systems can have only one Phase 2 entry.

    Thank you for your replay.
    We only have one phase 2 entry per IPSEC tunnel. (See attachment)

    is this where I am going wrong?




  • @NASMAN:

    We only have one phase 2 entry per IPSEC tunnel. (See attachment)

    is this where I am going wrong?

    As long as you understand what you are doing, everything seems to be o.k. I just guessed your configuration.

    I have never configured 0.0.0.0/0 network as a part of side to side vpn. O.k., it seems you want, that whole AWS traffic goes through the VPN tunnel.

    Do you allow ICMP traffic between 192.2.0.0/24 and 10.0.0.0/16 on IPsec interface?

    P.S. In my side to side vpn configurations only the traffic between local networks is allowed to go through the tunnel.
    This is why I would create two phase 2 entries for "Amazon-IKE-vpn" - one for 192.1.1.0/24, another for 192.2.0.0/24. But it is not your case.



  • The setup I am looking for is for all local office users and all remote VPN users to be able to connect to all AWS servicers (Eg servers, storage).

    Lets say here is some IP's:
    10.0.5.43 = AWS server
    192.1.1.10 = office server
    192.2.0.5 = VPN remote user

    192.1.1.10 can ping 10.0.5.43 (office can ping AWS)
    10.0.5.43 can ping 192.1.1.10 (AWS can ping office)

    192.1.1.10 can ping 192.2.0.5 (office can ping VPN user)
    192.2.0.5 can ping 192.1.1.10 (VPN user can ping office)

    10.0.5.43 can NOT ping 192.2.0.5 (AWS can NOT ping VPN user)
    192.2.0.5 can NOT ping 10.0.5.43 (VPN user can NOT ping AWS)

    Q: "Do you allow ICMP traffic between 192.2.0.0/24 and 10.0.0.0/16 on IPsec interface?"
    A: What do you mean by interface? IPSEC firewall? See attachment Capture1.jpg (BTW GuestDMZ is guest WiFi).

    Q: "This is why I would create two phase 2 entries for "Amazon-IKE-vpn" - one for 192.1.1.0/24, another for 192.2.0.0/24. But it is not your case"
    A: I did only have 10.0.0.0/16 set on "Local Network" on phase 2 for AWS but I set it to 0.0.0.0/0 for testing.

    I don't no what I am missing. I think I am so close…...
    If we did not have remote VPN users then this setup works perfect. lol

    When I think about it, it sounds easy.
    Route 10.0.0.0/16 from IPSEC1 down IPSEC2.

    I think the traffic is just getting lost. Is there anyway to check this?
    Or do you have any different idea. I can change anything needed to test. (I am going mad with it now haha)




  • @NASMAN:

    When I think about it, it sounds easy.
    Route 10.0.0.0/16 from IPSEC1 down IPSEC2.

    As far as I know, IPsec routing is not so flexible (as OpenVpns). Maybe it is the case.

    @NASMAN:

    I think the traffic is just getting lost. Is there anyway to check this?

    Sorry, I do not know. I use traceroute, ping, wireshark. Maybe netstat or tcpdump? In this case it is relative clear, that the traffic disappears between IPsec interfaces.

    @NASMAN:

    Or do you have any different idea. I can change anything needed to test. (I am going mad with it now haha)

    Try to configure two phase 2 entries for "Amazon-IKE-vpn" - one for 192.1.1.0/24 <-> 10.0.0.0/16, another for 192.2.0.0/24 <-> 10.0.0.0/16. Pay attention,  the networks other than 192.1.1.0/24, 192.2.0.0/24 will not be accessible from AWS through the vpn.



  • @yarick123:

    @NASMAN:

    When I think about it, it sounds easy.
    Route 10.0.0.0/16 from IPSEC1 down IPSEC2.

    As far as I know, IPsec routing is not so flexible (as OpenVpns). Maybe it is the case.

    @NASMAN:

    I think the traffic is just getting lost. Is there anyway to check this?

    Sorry, I do not know. I use traceroute, ping, wireshark. Maybe netstat or tcpdump? In this case it is relative clear, that the traffic disappears between IPsec interfaces.

    @NASMAN:

    Or do you have any different idea. I can change anything needed to test. (I am going mad with it now haha)

    Try to configure two phase 2 entries for "Amazon-IKE-vpn" - one for 192.1.1.0/24 <-> 10.0.0.0/16, another for 192.2.0.0/24 <-> 10.0.0.0/16. Pay attention,  the networks other than 192.1.1.0/24, 192.2.0.0/24 will not be accessible from AWS through the vpn.

    Q: "As far as I know, IPsec routing is not so flexible (as OpenVpns). Maybe it is the case."
    A: I cannot use OpenVPN with AWS.

    Q: "Sorry, I do not know. I use traceroute, ping, wireshark. Maybe netstat or tcpdump? In this case it is relative clear, that the traffic disappears between IPsec interfaces."
    A: Yes I also think this.

    Q: Try to configure two phase 2 entries for "Amazon-IKE-vpn" - one for 192.1.1.0/24 <-> 10.0.0.0/16, another for 192.2.0.0/24 <-> 10.0.0.0/16. Pay attention,  the networks other than 192.1.1.0/24, 192.2.0.0/24 will not be accessible from AWS through the vpn.
    A: See attached files
    I still cannot ping 10.0.5.43 from VPN user. (But office server can ping AWS server still)

    Is it got anything to do with how the VPN is setup for the remote users maybe.

    Lets say AWS VPC VPN was blocking 192.2.0.0/24 pings, I would still be able to ping a VPN user from AWS (with no firewall) So I don't think this is AWS at this time.






  • ITS WORKING!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    ;D ;D ;D ;D ;D ;D ;D ;D

    I am going to check from inside the office tomorrow.

    But…...

    ALL WORKS

    Lets say here is some IP's:
    10.0.5.43 = AWS server
    192.1.1.10 = office server
    192.2.0.5 = VPN remote user

    192.1.1.10 can ping 10.0.5.43 (office can ping AWS)
    10.0.5.43 can ping 192.1.1.10 (AWS can ping office)

    192.1.1.10 can ping 192.2.0.5 (office can ping VPN user)
    192.2.0.5 can ping 192.1.1.10 (VPN user can ping office)

    10.0.5.43 can ping 192.2.0.5 (AWS can ping VPN user)
    192.2.0.5 can ping 10.0.5.43 (VPN user can ping AWS)



  • P.S. I think, this is it:

    The mentioned distinction between policies and SAs often leads to misconceptions. For instance, referring to the image
    above, if host moon has a site-to-site tunnel to host sun (connecting the two networks 10.1.0.0/24 and 10.2.0.0/24),
    and host carol has a roadwarrior connection to host sun (from which carol received a virtual IP address of 10.3.0.10),
    then carol wont be able to automatically communicate with alice, even if forwarding is enabled on sun. This is because
    there is no IPsec policy allowing traffic between carol (10.3.0.10) and alice (10.1.0.10). An additional SA between moon
    and sun, connecting the virtual subnet 10.3.0.0/24 with 10.1.0.0/24 would be a possible solution to this issue.

    source: https://wiki.strongswan.org/projects/strongswan/wiki/IntroductiontostrongSwan#IKE-and-IPsec-Basics



  • Are you aware that 192.0.0.1-192.167.255.255 are public addresses and shouldn't be used for private use unless assigned to you by your ISP? 192.1.x.x and 192.2.x.x fall into that range.



  • @ikkuranus:

    Are you aware that 192.0.0.1-192.167.255.255 are public addresses and shouldn't be used for private use unless assigned to you by your ISP? 192.1.x.x and 192.2.x.x fall into that range.

    Yes I am aware ;)

    Its all working now with the setup we need.

    Thank You