Navigation

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

    Only 1 Cisco VPN client (Ipsec over UDP) can connect to remote IP at a time

    IPsec
    4
    9
    11153
    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.
    • S
      sb1 last edited by

      Cisco client Ipsec over UDP tunnels fail when >1 connects behind pfSense

      WAN-> |pfSense1.2| <-LAN

      We have contractors working out of our facility who use Cisco VPN clients (4.8.02.0010) on XP laptops to connect to their parent company.  Their VPN clients are configured to connect via IPSec over UDP (NAT/PAT).  One contractor can connect, and ping addresses on the remote side (parent company) without issue.  If a second client connects from the LAN side to the same IP, his client appears to Connect successfully, and gets an IP address.  However, the second client can not ping any remote addresses.  The same issue occurs with subsequent connections.  I should point out that the first connection continues to function, after subsequent IPSec connections are established to the remote IP (as noted those subsequent connections appear as connected, but fail to ping remote addresses).

      If they associate with our neighbors open wireless connection (and disconnect from our LAN), all three contractors can connect via their Cisco VPN clients to their parent company at the same time, and ping any address on the remote LAN.  The neighbor is using a soho-type firewall (a Linksys if I recall correctly).  On our side, we're running pfSense 1.2, and have one internet connection with multiple static IPs (we're only using two currently, 1 is a VIP proxyArp).  We have ipsec pass-through enabled (NAT>Outbound>Automatic).

      Does anyone have any ideas on this?  I'm certain that the Cisco client is not a PPTP VPN (first thing I checked). Thank you for your help!

      1 Reply Last reply Reply Quote 0
      • S
        sb1 last edited by

        While reading the VPN Capability IPSec post (http://doc.pfsense.org/index.php/VPN_Capability_IPSec), I noticed the following statement:

        pfSense does not support NAT-Traversal (NAT-T) for IPsec, which means if any of your client machines are behind NAT, IPsec VPN will not work.

        I realize that they're referring to remote clients connecting into pfSense via IPSec, but would the reverse also be true?  For instance, in the above scenario with contractors inside my LAN connecting out via Cisco IPSec into a remote concentrator (passing through pfSense), since pfSense does not support NAT-T - would that cause the symptoms I'm looking at?  E.g… one contractor can connect from my LAN into the remote Cisco concentrator, but subsequent connecting can't communicate with remote hosts?

        Any help would be greatly appreciated!

        1 Reply Last reply Reply Quote 0
        • L
          lambert last edited by

          I can't remember if you have to have NAT-T on the router or just the far end VPN termination point.

          I do remember, at some point, being unable to connect two clients on our LAN to the same off-site VPN network.  I'm not sure if the problem was fixed by enabling NAT-T on the off-site PIX or if I'm just mis-remembering and it was all PPTP.  I am not at the office right now to test things, but I think with NAT-T using UDP or TCP, multiple clients should work from behind pfSense.  They should just look like any other application at that point.

          I found this on http://forum.pfsense.org/index.php/topic,7001.msg39657.html#msg39657

          If you are running IPsec or VoiP clients in your network you might want to enable the static port option. The same goes for most games.
          more info on that here: http://doc.pfsense.org/index.php/Static_Port

          However, it is late and I have not thought about this problem in quite a while (multiple years).  I could be completely wrong.  But it might be something to try…

          1 Reply Last reply Reply Quote 0
          • C
            cmb last edited by

            @sb1:

            pfSense does not support NAT-Traversal (NAT-T) for IPsec, which means if any of your client machines are behind NAT, IPsec VPN will not work.

            This only applies when pfSense is the IPsec endpoint, not when it's passing the traffic.

            Cisco VPN client works fine with multiple connections as long as NAT-T is enabled on the Cisco.

            1 Reply Last reply Reply Quote 0
            • S
              sb1 last edited by

              Cisco VPN client works fine with multiple connections as long as NAT-T is enabled on the Cisco.

              Thanks for the follow-up.  Could you speculate as to why I'm able to have multiple connections when I'm using a home-office style firewall (e.g Linksys BEFSX41)?  Over the weekend I put an old Linksys BEFSX41 at my perimeter (at home) and tried to establish multiple IPSec connections to this particular remote host.  I was able to do so without incident from multiple machines.  While I realize that NAT-T needs to be enabled on the remote Cisco concentrator - the question I'm getting from the on-site contractors is - "why does this work next door, and not at your office?".  Thanks for the help… if you can take a stab at answering the question my contractors as posing, it would be very helpful!

              1 Reply Last reply Reply Quote 0
              • S
                sb1 last edited by

                So no ideas at all why this works on the lower end/soho firewalls… like from Linksys?  I'd be more than willing to shoot over some cash via paypal for a good explanation here.  Thanks!

                1 Reply Last reply Reply Quote 0
                • C
                  cmb last edited by

                  Likely the fact that pf rewrites the source port to enhance security and your typical run of the mill Linksys doesn't do anything to really secure your network other than hiding you behind NAT.

                  NAT-T needs to be enabled on the Cisco.

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

                    sb1,

                    Did you ever manage to find out what was wrong and how to fix this problem either on your end or on your contractor's company end?

                    I am having the same exact issue here, and wanted to know if i should bother to go and call the other company to ask them to turn on NAT-Traversal.

                    Thanks.

                    1 Reply Last reply Reply Quote 0
                    • S
                      sb1 last edited by

                      No - we never did get this resolved.

                      We engaged the contractor's parent company to see if they could enable NAT traversal, or at least look into it - but beyond saying that they would look into it, were not able to get any attention on the topic.  The immediate project need has diminished - as the initial scope was completed - but I envision this coming back up again soon.  If I knew exactly what they were doing on their end I would try to reproduce the scenario, but as it stands we're at a dead-end until it the need comes back up, or until we run into a similar issue with a different client.

                      If you make any progress on this in the iterim - I would love to hear about it - please post and/or PM me.  I'll of course do the same if/when it becomes an issue again for us.

                      Thanks!

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post

                      Products

                      • Platform Overview
                      • TNSR
                      • pfSense
                      • Appliances

                      Services

                      • Training
                      • Professional Services

                      Support

                      • Subscription Plans
                      • Contact Support
                      • Product Lifecycle
                      • Documentation

                      News

                      • Media Coverage
                      • Press
                      • Events

                      Resources

                      • Blog
                      • FAQ
                      • Find a Partner
                      • Resource Library
                      • Security Information

                      Company

                      • About Us
                      • Careers
                      • Partners
                      • Contact Us
                      • Legal
                      Our Mission

                      We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                      Subscribe to our Newsletter

                      Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                      © 2021 Rubicon Communications, LLC | Privacy Policy