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 -
@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?
-
@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?
-
@viragomann Here's my outbound NAT:
-
@utnuc
Seems you OpenVPN server is running in tap mode.
Any good reason for this? -
@viragomann I'm in tun mode. Here's my openVPN config.
-
@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. -
@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.
-
@johnpoz
Ah, this could be the reason for sure. -
@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.
-
@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.
-
@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.
-
@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.
-
@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.
That is what comes to mine when you say the fqdn resolves to the correct IP.
-
@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.
-
@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 ;)
