[GH-ISSUE #233] Failure to use local DNS server

kerem commented

2026-03-02 07:44:49 +03:00

Owner

Originally created by @pindab0ter on GitHub (Feb 28, 2021).
Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/233

Checklist

I read the README
I read the Important notes
I followed instructions to configure VPN clients
I checked Troubleshooting, enabled logs and checked VPN status
I searched existing Issues
This bug is about the IPsec VPN server Docker image, and not IPsec VPN itself

Describe the issue
When setting VPN_DNS_SRV1=192.168.0.201 (which is the address of my local DNS server) requests to my *.local-domains fail to be properly resolved.

To Reproduce
Steps to reproduce the behavior:

Set up the docker container using:

volumes:
  ikev2-vpn-data:

services:
  [Other services omitted]
  vpn:
    container_name: vpn
    image: hwdsl2/ipsec-vpn-server
    restart: unless-stopped
    ports: 
      - 500:500/udp
      - 4500:4500/udp
    volumes: 
      - /lib/modules:/lib/modules:ro
      - ikev2-vpn-data:/etc/ipsec.d
    environment:
      PUID: 1000
      GUID: 1000
    env_file: 
      - ./vpn.env
    privileged: true

vpn.env:

VPN_IPSEC_PSK=[...]
VPN_USER=[...]
VPN_PASSWORD=[...]
VPN_DNS_NAME=[...]
VPN_DNS_SRV1=192.168.0.201

Connect through IKEv2 using the vpnclient.mobileconfig file
Try to visit *.local-domains

Expected behavior
I expect the domain to be resolved by the local DNS server.

Logs
Enable logs, check VPN status, and add error logs to help explain the problem, if applicable.

Server (please complete the following information)

Docker host OS: Debian 10
Hosting provider (if applicable): self-hosted

Client (please complete the following information)

Device: iPhone XS
OS: 14.4
VPN mode: IKEv2

Additional context

Local DNS resolves correctly when part of the same network
IKEv2 connection successfully established. Using this connection:
- Non-local DNS resolves successfully
- Visiting the local DNS server directly using it's IP address works
Pinging the local DNS server from within the running container using it's IP address shows that the local DNS server is reachable

Does the fact that the DNS server assigns to a different subnet (192.168.42.###) have anything to do with this? The fact that I'm able to ping the DNS server directly from within the container makes me think no.

Originally created by @pindab0ter on GitHub (Feb 28, 2021). Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/233 **Checklist** - [x] I read the [README](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md) - [x] I read the [Important notes](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#important-notes) - [x] I followed instructions to [configure VPN clients](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#next-steps) - [x] I checked [Troubleshooting](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#troubleshooting), [enabled logs](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#enable-libreswan-logs) and checked [VPN status](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#check-logs-and-vpn-status) - [x] I searched existing [Issues](https://github.com/hwdsl2/docker-ipsec-vpn-server/issues?q=is%3Aissue) - [x] This bug is about the IPsec VPN server Docker image, and not IPsec VPN itself  **Describe the issue** When setting `VPN_DNS_SRV1=192.168.0.201` (which is the address of my local DNS server) requests to my *.local-domains fail to be properly resolved. **To Reproduce** Steps to reproduce the behavior: 1. Set up the docker container using: ``` volumes: ikev2-vpn-data: services: [Other services omitted] vpn: container_name: vpn image: hwdsl2/ipsec-vpn-server restart: unless-stopped ports: - 500:500/udp - 4500:4500/udp volumes: - /lib/modules:/lib/modules:ro - ikev2-vpn-data:/etc/ipsec.d environment: PUID: 1000 GUID: 1000 env_file: - ./vpn.env privileged: true ``` `vpn.env`: ``` VPN_IPSEC_PSK=[...] VPN_USER=[...] VPN_PASSWORD=[...] VPN_DNS_NAME=[...] VPN_DNS_SRV1=192.168.0.201 ``` 2. Connect through IKEv2 using the `vpnclient.mobileconfig` file 3. Try to visit `*.local`-domains **Expected behavior** I expect the domain to be resolved by the local DNS server. **Logs** [Enable logs](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/master/README.md#enable-libreswan-logs), check [VPN status](https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#check-logs-and-vpn-status), and add error logs to help explain the problem, if applicable. **Server (please complete the following information)** - Docker host OS: Debian 10 - Hosting provider (if applicable): self-hosted **Client (please complete the following information)** - Device: iPhone XS - OS: 14.4 - VPN mode: IKEv2 **Additional context** * Local DNS resolves correctly when part of the same network * IKEv2 connection successfully established. Using this connection: * Non-local DNS resolves successfully * Visiting the local DNS server directly using it's IP address works * Pinging the local DNS server from within the running container using it's IP address shows that the local DNS server is reachable Does the fact that the DNS server assigns to a different subnet (`192.168.42.###`) have anything to do with this? The fact that I'm able to ping the DNS server directly from within the container makes me think no.

kerem closed this issue

2026-03-02 07:44:49 +03:00

kerem commented

2026-03-02 07:44:50 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Feb 28, 2021):

@pindab0ter Hello! This is probably unrelated to the different subnet you mentioned. I think that your use case can work, by adding the modecfgdomains option to /etc/ipsec.d/ikev2.conf. Reference: [1][2]. Try:

# Replace ipsec-vpn-server with the name of your Docker container, if different
docker exec -it ipsec-vpn-server env TERM=xterm bash -l
# "modecfgdomains" must have two leading spaces in the command below
echo "  modecfgdomains=local" >> /etc/ipsec.d/ikev2.conf
service ipsec restart
exit

After that, re-connect your VPN client. Let us know if this works for your use case.

[1] https://libreswan.org/man/ipsec.conf.5.html
[2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/configuring-a-vpn-with-ipsec_securing-networks

@hwdsl2 commented on GitHub (Feb 28, 2021): @pindab0ter Hello! This is probably unrelated to the different subnet you mentioned. I think that your use case can work, by adding the `modecfgdomains` option to `/etc/ipsec.d/ikev2.conf`. Reference: [1][2]. Try: ``` # Replace ipsec-vpn-server with the name of your Docker container, if different docker exec -it ipsec-vpn-server env TERM=xterm bash -l # "modecfgdomains" must have two leading spaces in the command below echo " modecfgdomains=local" >> /etc/ipsec.d/ikev2.conf service ipsec restart exit ``` After that, re-connect your VPN client. Let us know if this works for your use case. [1] https://libreswan.org/man/ipsec.conf.5.html [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/configuring-a-vpn-with-ipsec_securing-networks

kerem commented

2026-03-02 07:44:50 +03:00

Author

Owner

@pindab0ter commented on GitHub (Mar 1, 2021):

Thank you for your fast follow-up. The suggested edit indeed works for my use case. Can this be made an optional setting or at least be added to the documentation? I'm also curious; does "local" in modecfgdomains=local refer to locally resolving domains or resolving .local domains?

@pindab0ter commented on GitHub (Mar 1, 2021): Thank you for your fast follow-up. The suggested edit indeed works for my use case. Can this be made an optional setting or at least be added to the documentation? I'm also curious; does "local" in `modecfgdomains=local` refer to locally resolving domains or resolving `.local` domains?

kerem commented

2026-03-02 07:44:50 +03:00

Author

Owner

@hwdsl2 commented on GitHub (Mar 2, 2021):

@pindab0ter Thanks for confirming. I think modecfgdomains=local refers to resolving .local domains. While using modecfgdomains makes sure that the specified internal domains must be resolved using the custom DNS server(s), it might cause all other DNS traffic (all domains other than .local in your use case) to go through the VPN client device's pre-configured DNS servers instead. See [1]. Quote:

VPN clients use the modecfgdomain value and the DNS entries to redirect queries for the specified domain to these specified nameservers. This allows roaming users to access internal-only resources using the internal DNS names.

For reference, the IETF internet draft related to this is [2].

Normally, I think client devices should use the custom DNS server(s) you specified in vpn.env for all DNS queries, if modecfgdomains is not specified. I'm not sure why .local doesn't work without this option in your use case. Perhaps it is related to Apple devices' special handling of .local domains (see [3])? If you have additional thoughts on this, feel free to reply.

As discussed above, the usage of this option is not entirely clear, so I'll probably not add it to the documentation at this time.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/road_warrior_application_using_libreswan_and_xauth_with_x.509
[2] https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-03
[3] https://serverfault.com/questions/47087/using-local-for-internal-websites

@hwdsl2 commented on GitHub (Mar 2, 2021): @pindab0ter Thanks for confirming. I think `modecfgdomains=local` refers to resolving `.local` domains. While using `modecfgdomains` makes sure that the specified internal domains must be resolved using the custom DNS server(s), it might cause all other DNS traffic (all domains other than `.local` in your use case) to go through the VPN client device's pre-configured DNS servers instead. See [1]. Quote: > VPN clients use the modecfgdomain value and the DNS entries to redirect queries for the specified domain to these specified nameservers. This allows roaming users to access internal-only resources using the internal DNS names. For reference, the IETF internet draft related to this is [2]. Normally, I think client devices should use the custom DNS server(s) you specified in `vpn.env` for all DNS queries, if `modecfgdomains` is not specified. I'm not sure why `.local` doesn't work without this option in your use case. Perhaps it is related to Apple devices' special handling of `.local` domains (see [3])? If you have additional thoughts on this, feel free to reply. As discussed above, the usage of this option is not entirely clear, so I'll probably not add it to the documentation at this time. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/road_warrior_application_using_libreswan_and_xauth_with_x.509 [2] https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-03 [3] https://serverfault.com/questions/47087/using-local-for-internal-websites

kerem commented

2026-03-02 07:44:51 +03:00

Author

Owner

@pindab0ter commented on GitHub (Mar 6, 2021):

I have changed my local domain from “.local” to something arbitrary and without any extra configuration in the VPN’s config the changes were picked up, ruling out modecfgdomains=local referring to the literal TLD.

I then removed that config line you suggested I add and ran service IPSec restart before reconnecting to the VPN. I was able to connect with the services ending on the new arbitrary TLD. So it seems like this is related to Apple devices’ handling of .local as you expected.

@pindab0ter commented on GitHub (Mar 6, 2021): I have changed my local domain from “.local” to something arbitrary and without any extra configuration in the VPN’s config the changes were picked up, ruling out `modecfgdomains=local` referring to the literal TLD. I then removed that config line you suggested I add and ran `service IPSec restart` before reconnecting to the VPN. I was able to connect with the services ending on the new arbitrary TLD. So it seems like this is related to Apple devices’ handling of `.local` as you expected.

Rows
Columns

[GH-ISSUE #233] Failure to use local DNS server #216