NAT VLAN through VPN Troubles
-
Hello All,
I am having a rather unique issue that I can not seem to figure out. In a nutshell, I can not connect to the webservers behind the vpn in a browser. Below are all the details and troubleshooting steps I have done so far. If anyone has any idea as to a solution I would be forever grateful.
Problem:
I have pfsense NAT-ing all my traffic on a VLAN through a VPN. I can not type in the IPs of webservers on the remote lab network and have their webpage display in a browser. I can get the page with wget or curl. If I add headers to the wget request though, it will produce the exact same issue as confirmed by wireshark.Note:
When I refer to "remote webservers" I am referring to the hosts behind the VPN in the 10.11.0.0/16 network. The attached captures came from pfsense under Diagnostics -> Packet Capture and I have confirmed that the captures are the same regardless of where it is captured from.Goal:
To be able to view the remote webservers through a browserTroubleshooting:
I verified that I can ping the remote webservers. I can also scan the hosts with nmap and get full detailed information.
The issue has been confirmed on Windows 10 (x64), Kali Linux (x64), and Kali Linux (x86)
The issue has been confirmed on Chrome, Internet Explorer, and Firefox.
On all OS-es I can use wget/curl to download the index.html file without issue. ( See packetcapture_good.cap )
When using any browser the request will time out after a certain amount of requests. ( See packetcapture_bad.cap )
Verified under Status -> OpenVPN that I am connected and getting Bytes Sent and Received
Verified that OpenVPN, OVPN, and UNTRUSTED33 (local vlan) have a permit all rule under Firewall -> Rules -> $(Interface)
Verified that I am using Manual Outbound NAT and that all trafic from the 33 VLAN is being sent to 10.11.0.0/16. ( See Below Photo )
The following command allows me to download the index.html file:wget 10.11.1.13The following command replicates the issue with the browser:
wget 10.11.1.13 --header="User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" --header="Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --header="Accept-Language: en-US,en;q=0.5" --header="Accept-Encoding: gzip, deflate" --header="Connection: keep-alive" --header="Upgrade-Insecure-Requests: 1" -vThe following command removes the above issue:
wget 10.11.1.13 --header="User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" --header="Accept: text/html,application/xhtml+xml" -vWhen connecting any one of my local hosts to the VPN directly, I can view the remote webservers without issue
Temporary Solution:
I used a Firefox extension called Simply Modify Headers that allows me to remove the parts of and or the whole headers that seem to be causing the issue. However, this is not exactly stable and is only a bandaid fix.I do not know of any other information that I could provide but I will gladly do my best to provide whatever is asked.
Thanks Everyone!
-
@picnicsecurity said in NAT VLAN through VPN Troubles:
Upgrade-Insecure-Requests
My take would be server your talking to doesn't understand this.
Not sure why you think this has anything to do with natting or pfsense.
-
@johnpoz I thought so too but then why would that header then work just fine when using the VPN directly? I honestly do not know if this a NAT or pfsense problem and the only reason I decided to post here was because when I removed pfsense from the equation it worked. I wasn't sure how else to narrow down the culprit.
-
On your VPN client, add
mssfix 1400to it's config file and try again.
-
@Pippin Thank you for the reply. I went into VPN -> OpenVPN -> Clients and edited my client's configuration. Under Advanced Configuration I put into the custom options "ns-cert-type server; persist-tun; persist-key; mssfix 1400" and then saved. I then reloaded the VPN by going to Status -> OpenVPN. I did the usual ping/nmap verification checks to confirm connectivity. However this does not seem to have done anything. Below is a picture of the wireshark output (with the TCP stream from the browser being currently selected) and below that is the capture file.
