<![CDATA[Client can't see LAN servers after connect]]>Hey guys, I hoping someone has a quick fix to my situation. I had a working OpenVPN configuration, then I changed my IPv4 Address on the LAN for the pfsense server from 10.0.0.1 to 10.0.0.2. I can still connect to the VPN, but now getting some connection errors on the client side and cannot connect to any LAN or WAN servers. Tunnelblick log posted below.

If it helps, another service stopped working when I did this: The DNS resolver is used to direct my subdomain pfsense.sonoclipshare.com to 10.0.0.2. When I test this subdomain using DNS Lookup I do get 10.0.0.2, but when I try to visit pfsense.sonoclipshare.com:1433 (the port my webconfigurator is configured for) it fails to connect. If course, 10.0.0.2:1433 works just fine.

Is this a firewall problem?

Tunnelblick LOG

2024-01-21 22:51:06.362676 *Tunnelblick: macOS 14.2.1 (23C71); Tunnelblick 4.0.0beta13 (build 5930)
2024-01-21 22:51:06.650728 *Tunnelblick: Cannot recognize the pfSense-TCP4-1194-config-loadTap preference value of '(null)', so Tunnelblick will not load the tap kext
2024-01-21 22:51:06.654039 *Tunnelblick: Attempting connection with pfSense-TCP4-1194-config using shadow copy; Set nameserver = 0x00000301; monitoring connection
2024-01-21 22:51:06.654472 *Tunnelblick: openvpnstart start pfSense-TCP4-1194-config.tblk 57492 0x00000301 0 1 0 0x0210c130 -ptADGNWradsgnw 2.5.9-openssl-1.1.1w <password>
2024-01-21 22:51:06.682688 *Tunnelblick: openvpnstart starting OpenVPN
2024-01-21 22:51:07.093586 OpenVPN 2.5.9 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Nov 21 2023
2024-01-21 22:51:07.093744 library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.10
2024-01-21 22:51:07.095417 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:57492
2024-01-21 22:51:07.095486 Need hold release from management interface, waiting...
2024-01-21 22:51:07.921203 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5.9-openssl-1.1.1w/openvpn
          --daemon
          --log-append /Library/Application Support/Tunnelblick/Logs/-SUsers-Sbenjaminsmith-SLibrary-SApplication Support-STunnelblick-SConfigurations-SpfSense--TCP4--1194--config.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_34652464.57492.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/benjaminsmith/pfSense-TCP4-1194-config.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5930 4.0.0beta13 (build 5930)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/benjaminsmith/pfSense-TCP4-1194-config.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/benjaminsmith/pfSense-TCP4-1194-config.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/benjaminsmith/pfSense-TCP4-1194-config.tblk/Contents/Resources
          --management 127.0.0.1 57492 /Library/Application Support/Tunnelblick/Mips/pfSense-TCP4-1194-config.tblk.mip
          --setenv IV_SSO webauth
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2024-01-21 22:51:07.922873 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:57492
2024-01-21 22:51:07.942825 MANAGEMENT: CMD 'pid'
2024-01-21 22:51:07.942904 MANAGEMENT: CMD 'auth-retry interact'
2024-01-21 22:51:07.942932 MANAGEMENT: CMD 'state on'
2024-01-21 22:51:07.942955 MANAGEMENT: CMD 'state'
2024-01-21 22:51:07.942983 MANAGEMENT: CMD 'bytecount 1'
2024-01-21 22:51:07.942987 *Tunnelblick: Established communication with OpenVPN
2024-01-21 22:51:07.943695 *Tunnelblick: >INFO:OpenVPN Management Interface Version 3 -- type 'help' for more info
2024-01-21 22:51:07.944139 MANAGEMENT: CMD 'hold release'
2024-01-21 22:51:07.947578 *Tunnelblick: Obtained VPN username and password from the Keychain
2024-01-21 22:51:07.948224 MANAGEMENT: CMD 'username "Auth" "ben"'
2024-01-21 22:51:07.948305 MANAGEMENT: CMD 'password [...]'
2024-01-21 22:51:07.948579 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-01-21 22:51:07.949459 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2024-01-21 22:51:07.949493 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
2024-01-21 22:51:07.949587 TCP/UDP: Preserving recently used remote address: [AF_INET]45.43.111.178:1194
2024-01-21 22:51:07.949678 Socket Buffers: R=[131072->131072] S=[131072->131072]
2024-01-21 22:51:07.949695 Attempting to establish TCP connection with [AF_INET]45.43.111.178:1194 [nonblock]
2024-01-21 22:51:07.949710 MANAGEMENT: >STATE:1705895467,TCP_CONNECT,,,,,,
2024-01-21 22:51:07.953041 TCP connection established with [AF_INET]45.43.111.178:1194
2024-01-21 22:51:07.953089 TCPv4_CLIENT link local: (not bound)
2024-01-21 22:51:07.953103 TCPv4_CLIENT link remote: [AF_INET]45.43.111.178:1194
2024-01-21 22:51:07.953143 MANAGEMENT: >STATE:1705895467,WAIT,,,,,,
2024-01-21 22:51:07.956528 MANAGEMENT: >STATE:1705895467,AUTH,,,,,,
2024-01-21 22:51:07.956576 TLS: Initial packet from [AF_INET]45.43.111.178:1194, sid=a6b233ed f1c4739e
2024-01-21 22:51:07.956660 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2024-01-21 22:51:07.968481 VERIFY OK: depth=1, CN=MineCraftVPN, C=US, ST=TN, L=Chattanooga, O=Smith House
2024-01-21 22:51:07.968709 VERIFY KU OK
2024-01-21 22:51:07.968727 Validating certificate extended key usage
2024-01-21 22:51:07.968735 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2024-01-21 22:51:07.968751 VERIFY EKU OK
2024-01-21 22:51:07.968766 VERIFY OK: depth=0, CN=MineCraftVPN, C=US, ST=TN, L=Chattanooga, O=Smith House
2024-01-21 22:51:07.980875 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2024-01-21 22:51:07.980945 [MineCraftVPN] Peer Connection Initiated with [AF_INET]45.43.111.178:1194
2024-01-21 22:51:08.374569 MANAGEMENT: >STATE:1705895468,GET_CONFIG,,,,,,
2024-01-21 22:51:08.374712 SENT CONTROL [MineCraftVPN]: 'PUSH_REQUEST' (status=1)
2024-01-21 22:51:08.374785 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 1.1.1.1,dhcp-option DNS 8.8.8.8,dhcp-option DNS 9.9.9.9,redirect-gateway def1,route-gateway 10.0.0.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.0.0.3 255.255.255.0,peer-id 1,cipher AES-256-GCM'
2024-01-21 22:51:08.374895 OPTIONS IMPORT: timers and/or timeouts modified
2024-01-21 22:51:08.374914 OPTIONS IMPORT: --ifconfig/up options modified
2024-01-21 22:51:08.374929 OPTIONS IMPORT: route options modified
2024-01-21 22:51:08.374944 OPTIONS IMPORT: route-related options modified
2024-01-21 22:51:08.374959 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-01-21 22:51:08.374974 OPTIONS IMPORT: peer-id set
2024-01-21 22:51:08.374988 OPTIONS IMPORT: adjusting link_mtu to 1626
2024-01-21 22:51:08.375003 OPTIONS IMPORT: data channel crypto options modified
2024-01-21 22:51:08.375020 Data Channel: using negotiated cipher 'AES-256-GCM'
2024-01-21 22:51:08.375187 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2024-01-21 22:51:08.375226 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2024-01-21 22:51:08.375631 Opened utun device utun4
2024-01-21 22:51:08.375653 MANAGEMENT: >STATE:1705895468,ASSIGN_IP,,10.0.0.3,,,,
2024-01-21 22:51:08.375666 /sbin/ifconfig utun4 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2024-01-21 22:51:08.386042 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2024-01-21 22:51:08.386124 /sbin/ifconfig utun4 10.0.0.3 10.0.0.3 netmask 255.255.255.0 mtu 1500 up
2024-01-21 22:51:08.392134 /sbin/route add -net 10.0.0.0 10.0.0.3 255.255.255.0
                           route: writing to routing socket: File exists
                           add net 10.0.0.0: gateway 10.0.0.3: File exists
2024-01-21 22:51:08.403873 /sbin/route add -net 45.43.111.178 10.0.0.2 255.255.255.255
                           add net 45.43.111.178: gateway 10.0.0.2
2024-01-21 22:51:08.407813 /sbin/route add -net 0.0.0.0 10.0.0.1 128.0.0.0
                           add net 0.0.0.0: gateway 10.0.0.1
2024-01-21 22:51:08.414458 /sbin/route add -net 128.0.0.0 10.0.0.1 128.0.0.0
                           add net 128.0.0.0: gateway 10.0.0.1
                           22:51:08 *Tunnelblick:  **********************************************
                           22:51:08 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           22:51:10 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN'
                           22:51:10 *Tunnelblick:  Disabled IPv6 for 'USB 10/100/1000 LAN 2'
                           22:51:10 *Tunnelblick:  Disabled IPv6 for 'AX88179A'
                           22:51:10 *Tunnelblick:  Disabled IPv6 for 'Thunderbolt Bridge'
                           22:51:10 *Tunnelblick:  Disabled IPv6 for 'Wi-Fi'
                           22:51:10 *Tunnelblick:  Retrieved from OpenVPN: name server(s) [ 1.1.1.1 8.8.8.8 9.9.9.9 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
                           22:51:10 *Tunnelblick:  Not aggregating ServerAddresses because running on macOS 10.6 or higher
                           22:51:10 *Tunnelblick:  Setting search domains to 'openvpn' because the search domains were not set manually (or are allowed to be changed) and 'Prepend domain name to search domains' was not selected
                           22:51:12 *Tunnelblick:  Saved the DNS and SMB configurations so they can be restored
                           22:51:12 *Tunnelblick:  Changed DNS ServerAddresses setting from '10.0.0.2' to '1.1.1.1 8.8.8.8 9.9.9.9'
                           22:51:12 *Tunnelblick:  Changed DNS SearchDomains setting from 'ultrasoundoftheweek.com' to 'openvpn'
                           22:51:12 *Tunnelblick:  Changed DNS DomainName setting from '' to 'openvpn'
                           22:51:12 *Tunnelblick:  Did not change SMB NetBIOSName setting of 'MAC-34817D'
                           22:51:12 *Tunnelblick:  Did not change SMB Workgroup setting of ''
                           22:51:12 *Tunnelblick:  Did not change SMB WINSAddresses setting of '192.168.1.1 192.168.1.1'
                           22:51:12 *Tunnelblick:  DNS servers '1.1.1.1 8.8.8.8 9.9.9.9' will be used for DNS queries when the VPN is active
                           22:51:12 *Tunnelblick:  The DNS servers include only free public DNS servers known to Tunnelblick.
                           22:51:12 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           22:51:12 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           22:51:12 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           22:51:12 *Tunnelblick:  Notified mDNSResponderHelper that the DNS cache was flushed
                           22:51:12 *Tunnelblick:  Setting up to monitor system configuration with process-network-changes
                           22:51:12 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           22:51:12 *Tunnelblick:  **********************************************
2024-01-21 22:51:12.394834 Initialization Sequence Completed
2024-01-21 22:51:12.394858 MANAGEMENT: >STATE:1705895472,CONNECTED,SUCCESS,10.0.0.3,45.43.111.178,1194,10.0.0.123,55337
2024-01-21 22:51:14.356873 *Tunnelblick: Routing info stdout:
   route to: 1.1.1.1
destination: 1.1.1.1
    gateway: 10.0.0.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
stderr:

2024-01-21 22:51:14.363405 *Tunnelblick: Warning: DNS server Address 1.1.1.1 is a known public DNS server but is not being routed through the VPN
2024-01-21 22:51:14.461348 *Tunnelblick: Routing info stdout:
   route to: 8.8.8.8
destination: 8.8.8.8
    gateway: 10.0.0.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
stderr:

2024-01-21 22:51:14.466074 *Tunnelblick: Warning: DNS server Address 8.8.8.8 is a known public DNS server but is not being routed through the VPN
2024-01-21 22:51:14.569029 *Tunnelblick: Routing info stdout:
   route to: 9.9.9.9
destination: 9.9.9.9
    gateway: 10.0.0.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 
stderr:

2024-01-21 22:51:14.574681 *Tunnelblick: Warning: DNS server Address 9.9.9.9 is a known public DNS server but is not being routed through the VPN
]]>https://forum.netgate.com/topic/185676/client-can-t-see-lan-servers-after-connectRSS for NodeWed, 10 Jun 2026 12:43:38 GMTMon, 22 Jan 2024 03:52:44 GMT60<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 03:37:40 GMT]]>@utnuc said in Client can't see LAN servers after connect:

creating an A-Record with cloudflare to point to 10.0.0.2,

Well that tells me your client isn't using your local dns then, but you said it resolved to 10.0.0.2 - so maybe your browser wasn't using your dns.. But using doh, the makers of the browsers being smarter than us love to point the browser to their dns vs you know the one we tell the OS to use ;)

]]>https://forum.netgate.com/post/1149053https://forum.netgate.com/post/1149053Tue, 23 Jan 2024 03:37:40 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 03:27:04 GMT]]>@johnpoz Yes, I have pfsense.sonoclipshare.com listed as an alternate host name, and DNS Resolver points that domain to 10.0.0.2. The page never loads, like a network timeout, as if the server isn't even there. I did get it working by actually creating an A-Record with cloudflare to point to 10.0.0.2, but this seems unnecessary since the DNS Resolver should take care of it locally.

]]>https://forum.netgate.com/post/1149052https://forum.netgate.com/post/1149052Tue, 23 Jan 2024 03:27:04 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 02:27:32 GMT]]>@utnuc said in Client can't see LAN servers after connect:

web configurator with pfsense.sonoclipshare.com

is that pfsense name? For example it defaults now to home.arpa - if your just pointing some name to it.. you would need to say set an alternate name.. Do you get some sort of error, your saying the page just doesn't load?

here is mine for example.
advanced.jpg

That is what comes to mine when you say the fqdn resolves to the correct IP.

]]>https://forum.netgate.com/post/1149047https://forum.netgate.com/post/1149047Tue, 23 Jan 2024 02:27:32 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 02:16:16 GMT]]>@utnuc Oh, one last thing. Everything works great: I can connect to the web configurator with pfsense.sonoclipshare.com, so the DNS resolver works. But when I connect to the VPN I can only connect to pfsense with 10.0.0.2. Stranger is that when I ping pfsense.sonoclipshare.com while connected, I get 10.0.0.2.

]]>https://forum.netgate.com/post/1149046https://forum.netgate.com/post/1149046Tue, 23 Jan 2024 02:16:16 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 01:43:10 GMT]]>@johnpoz said in Client can't see LAN servers after connect:

@utnuc your tunnel network should just be some other network that does not overlap with your existing network(s).. That is just a 2 second fix, change it.

As to your dns problem.. That could be related to your problem with overlapping tunnel network.

You also need to make sure your ACLs on unbound are allowing a query from whatever your tunnel network is.. if your using the automatic acls, I do believe they are auto allowed. If your using manual acls on unbound you would need to make sure your tunnel network is allowed.

Sometimes clients don't actually want to query the dns you hand out in your vpn config, validate your client can actually query whatever dns your handing it.. that resolves your local resources.

Thanks guys, changing the tunnel network fixed both problems! I really appreciate your expertise and time. Great community.

]]>https://forum.netgate.com/post/1149039https://forum.netgate.com/post/1149039Tue, 23 Jan 2024 01:43:10 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 00:30:48 GMT]]>@utnuc your tunnel network should just be some other network that does not overlap with your existing network(s).. That is just a 2 second fix, change it.

As to your dns problem.. That could be related to your problem with overlapping tunnel network.

You also need to make sure your ACLs on unbound are allowing a query from whatever your tunnel network is.. if your using the automatic acls, I do believe they are auto allowed. If your using manual acls on unbound you would need to make sure your tunnel network is allowed.

Sometimes clients don't actually want to query the dns you hand out in your vpn config, validate your client can actually query whatever dns your handing it.. that resolves your local resources.

]]>https://forum.netgate.com/post/1149024https://forum.netgate.com/post/1149024Tue, 23 Jan 2024 00:30:48 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Tue, 23 Jan 2024 00:04:30 GMT]]>@johnpoz Thanks. Is there an easy fix for this? I'm willing to reconfigure the VPN from scratch. Although I'm not sure if this will fix the problem with my DNS resolver.

]]>https://forum.netgate.com/post/1149019https://forum.netgate.com/post/1149019Tue, 23 Jan 2024 00:04:30 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 23:45:44 GMT]]>@johnpoz
Ah, this could be the reason for sure.

]]>https://forum.netgate.com/post/1149016https://forum.netgate.com/post/1149016Mon, 22 Jan 2024 23:45:44 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 23:33:52 GMT]]>@viragomann I think he is using the tunnel network same as his lan network.. Which is going be problematic for sure..

Here is mine for example.. You can see the tunnel networks are auto added to the outbound nat.
tunnel.jpg

]]>https://forum.netgate.com/post/1149014https://forum.netgate.com/post/1149014Mon, 22 Jan 2024 23:33:52 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 22:03:03 GMT]]>@utnuc
According to the client log, the server pushes the ifconfig 10.0.0.3/24, and as you said above 10.0.0.2 is the LAN IP of the server.
This could only happen if the server is in tap mode, however. Or there is something pretty faulty on the server.

Also in the outbound NAT, there are two entries 10.0.0.0/24.
Check out in Status > interfaces, which are using this subnet.

]]>https://forum.netgate.com/post/1149002https://forum.netgate.com/post/1149002Mon, 22 Jan 2024 22:03:03 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 20:35:59 GMT]]>@viragomann I'm in tun mode. Here's my openVPN config.
alt text

]]>https://forum.netgate.com/post/1148991https://forum.netgate.com/post/1148991Mon, 22 Jan 2024 20:35:59 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 18:52:19 GMT]]>@utnuc
Seems you OpenVPN server is running in tap mode.
Any good reason for this?

]]>https://forum.netgate.com/post/1148980https://forum.netgate.com/post/1148980Mon, 22 Jan 2024 18:52:19 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 17:55:54 GMT]]>@viragomann Here's my outbound NAT:
alt text

]]>https://forum.netgate.com/post/1148974https://forum.netgate.com/post/1148974Mon, 22 Jan 2024 17:55:54 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 17:21:54 GMT]]>@viragomann Hmm, in the Tunnelblick log I am seeing 10.0.0.1 as the gateway multiple places. When I look at System/Routing/Gateways all I see is the WAN gateway. Is there another place I need to look to change the gateway?

]]>https://forum.netgate.com/post/1148973https://forum.netgate.com/post/1148973Mon, 22 Jan 2024 17:21:54 GMT<![CDATA[Reply to Client can't see LAN servers after connect on Mon, 22 Jan 2024 08:57:18 GMT]]>@utnuc
Is pfSense the default gateway on the destination devices, you want to access?
Maybe you forgot to update the gateway.

Or if it isn't and you do masquerading with an outbound NAT rule, did you update it?

]]>https://forum.netgate.com/post/1148929https://forum.netgate.com/post/1148929Mon, 22 Jan 2024 08:57:18 GMT