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

    [2.2] Strong Swan DNS Problems with mobile users

    Scheduled Pinned Locked Moved
    IPsec
    8
    14
    6.2k
    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.
    • N
      networkninja
      last edited by

      Hello,

      We are having problems with mobile users using IPSec Xauth + Mutual PSK.

      Traffic can pass through the vpn just fine but DNS is not being handed out correctly. I have tried sending split-dns, not sending, but no matter what I do, our main name server is not being queried for DNS even though it's being provided as server #1. I have compared 2.1.5 to 2.2 and using Apple's "scutil –dns" I'm seeing some strange behavior from Strong Swan.

      With 2.1.5:

      DNS configuration

      resolver #1
        search domain[0] : xyz.com
        nameserver[0] : 172.20.10.1
        if_index : 4 (en0)
        flags    : Request A records
        reach    : Reachable,Directly Reachable Address

      resolver #2
        domain  : xyz.com
        nameserver[0] : 10.0.1.1
        flags    : Request A records
        reach    : Reachable,Transient Connection
        order    : 100200

      With 2.2:

      DNS configuration

      resolver #1
        search domain[0] : xyz.comp
        nameserver[0] : 172.20.10.1
        if_index : 4 (en0)
        flags    : Request A records
        reach    : Reachable,Directly Reachable Address

      resolver #2
        domain  : xyz.comp
        nameserver[0] : 10.0.1.1
        flags    : Request A records
        reach    : Reachable,Transient Connection
        order    : 100200

      Not sure where this extra "p" is coming from, but it seems to be possibly breaking DNS queries. I have SSH'd into the 2.2 setup and I cannot find a xyz.comp anywhere in the /var/etc/ipsec/* files.

      As of right now my only solution has been to revert back to 2.1.5 for mobile users.

      I have tried setting my phase2 to 0.0.0.0/0 but that did not change anything. Traffic is being routed just fine (when I ping etc via ip address) but DNS is not being handed out correctly.

      Anyone know what's going on here? Thanks in advance for any help.

      *xyz.com is made up

      1 Reply Last reply Reply Quote 0
      • N
        networkninja
        last edited by

        Can anyone confirm they are able to use pfSense 2.2 with IPsec IKE V1 Mutual PSK + Xauth connected to the built-in OS X "Cisco IPsec" client, and successfully supply a search domain and a Private DNS server that's only available within the VPN? I'm not able to get DNS to work with either Mac Desktops or iOS, along with a linux user who also said their DNS wasn't resolving correctly when connected to the 2.2 box.

        I have set DNS Server #1 to our internal DNS server. I have set provide a default domain to the clients. I have tried both setting and not setting the split-dns option. I have tried a p2 of 0.0.0.0/0 with no effect. I have tried providing and not providing a network list.

        At this point I'm just curious if anyone has gotten this to work so I can determine if it's likely a config/local issue or a bug.

        I'm able to ping anything on the internal network via IP address when connected to VPN, but I cannot get it to hand out a correct DNS configuration to our clients….

        Thanks!

        1 Reply Last reply Reply Quote 0
        • N
          networkninja
          last edited by

          btw - here are the logs from my mac connecting to 2.2:

          Feb  6 10:48:19 superfly.local racoon[1272]: IKE Packet: receive success. (MODE-Config).
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration started.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-ADDRESS = 172.16.90.1.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-DNS = 172.16.60.254.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: DEF-DOMAIN = xyz.com.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLITDNS-NAME[0] = xyz.comp.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLIT-INCLUDE.
          Feb  6 10:48:19 superfly kernel[0]: utun_ctl_connect: creating interface utun0
          Feb  6 10:48:19 superfly kernel[0]: utun0: is now delegating en8 (type 0x6, family 2, sub-family 0)
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Phase2 starting.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration established.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Phase1 established.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration started.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-ADDRESS = 172.16.90.1.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-DNS = 172.16.60.254.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: DEF-DOMAIN = xyz.com.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLITDNS-NAME[0] = xyz.comp.
          Feb  6 10:48:19 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLIT-INCLUDE.
          Feb  6 10:48:19 superfly.local configd[26]: network changed.

          This is happening even when I have Split DNS unchecked in the GUI.

          Here are the logs from a successful 2.1.5 connection in which everything works:

          Feb  6 10:53:28 superfly.local racoon[1272]: IKE Packet: receive success. (MODE-Config).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration started.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-ADDRESS = 10.5.0.2.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-MASK = 255.255.255.0.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SAVE-PASSWORD = 1.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-DNS = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: DEF-DOMAIN = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLITDNS-NAME[0] = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLIT-INCLUDE.
          Feb  6 10:53:28 superfly kernel[0]: utun_ctl_connect: creating interface utun0
          Feb  6 10:53:28 superfly kernel[0]: utun0: is now delegating en8 (type 0x6, family 2, sub-family 0)
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Phase2 starting.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration established.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Phase1 established.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration started.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-ADDRESS = 10.5.0.2.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-MASK = 255.255.255.0.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SAVE-PASSWORD = 1.
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: INTERNAL-IP4-DNS = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: DEF-DOMAIN = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLITDNS-NAME[0] = (null).
          Feb  6 10:53:28 superfly.local nesessionmanager[356]: IPSec Network Configuration: SPLIT-INCLUDE.
          Feb  6 10:53:28 superfly.local configd[26]: network changed.

          Very strange that when the relevant attributes are (null) the internal DNS server and search domain work fine.

          1 Reply Last reply Reply Quote 0
          • R
            rkuo
            last edited by

            I am having the exact same problem.  The upgrade to 2.2 broke DNS and I am seeing the same "p" appended to the domain, which is a bad sign, even tho I can't be sure.

            1 Reply Last reply Reply Quote 0
            • N
              networkninja
              last edited by

              Well I guess nobody cares except those that are affected by this…

              1 Reply Last reply Reply Quote 0
              • D
                dwood
                last edited by

                I was hung up in the same situation.  I took my first crack at OpenVPN which I got configured, routing and pushing out client install packages in about 15 minutes.  Very slick on both iOS and PC.

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by

                  @networkninja:

                  Well I guess nobody cares except those that are affected by this…

                  What's not reported cannot get fixed => https://redmine.pfsense.org/issues/4418

                  1 Reply Last reply Reply Quote 0
                  • D
                    dstroot
                    last edited by

                    For what it's worth I have asked several times about setting up an IPSEC VPN with a current version of iOS (apple iphone, not Cisco).  I can't get it to work for the life of me but for some reason vpn'ing back in via your iPhone or iPad doesn't seem to get a lot of attention here.  If I could figure it out I'd be happy to create a nice guide with screenshots, etc and hopefully put it up on the Wiki.

                    I feel OpenVPN (which does work well) is clunky and I would prefer a "built-in" option.

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

                      @doktornotor:

                      What's not reported cannot get fixed => https://redmine.pfsense.org/issues/4418

                      Thanks notor, I was already looking into it.

                      @dstroot:

                      but for some reason vpn'ing back in via your iPhone or iPad doesn't seem to get a lot of attention here.

                      Because it works perfectly fine. And there are instructions.
                      https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To
                      though the instructions in the 2.1x book are better in general, and equally applicable to 2.2.

                      I tend to have to limit my involvement here to things that are quickly addressable, or things indicative of a bug of some sort. We setup mobile IPsec for iOS for support customers all the time, and use it ourselves with iOS and OS X.

                      1 Reply Last reply Reply Quote 0
                      • E
                        eri--
                        last edited by

                        Can you please test the change done for https://redmine.pfsense.org/issues/4418 and report back?

                        1 Reply Last reply Reply Quote 0
                        • D
                          doktornotor Banned
                          last edited by

                          @ermal:

                          Can you please test the change done for https://redmine.pfsense.org/issues/4418 and report back?

                          Cannot see any commit there. In general, there seems to be some issue with Redmine showing commits with a significant delay.

                          EDIT: Finally there, took over 30 minutes  ???

                          1 Reply Last reply Reply Quote 0
                          • N
                            networkninja
                            last edited by

                            Thanks for looking into this!

                            1 Reply Last reply Reply Quote 0
                            • G
                              Garrett
                              last edited by

                              Just found a workaround by appending another bogus domain name in my split-dns list from: "mydomain.com" to "mydomain.com bogus.com". That seemed to do the trick.

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

                                @Garrett:

                                Just found a workaround by appending another bogus domain name in my split-dns list from: "mydomain.com" to "mydomain.com bogus.com". That seemed to do the trick.

                                That'll work around it. The root issue, which was a client-side problem, was fixed in OS X El Capitan for sure, and I believe a newer iOS version than this thread originally referenced as well.

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