Selective Remote Access
-
Is it possible in OpenVPN to create a user or group that only has access to one local server and nothing else?
-
You can use "Client Specific Overrides" to force specific IPs to one or more clients if your server do TLS/SSL-auth or set up an additional vpn server for that group.
Then you can control access by firewall rules. -
You can use "Client Specific Overrides" to force specific IPs to one or more clients if your server do TLS/SSL-auth or set up an additional vpn server for that group.
Then you can control access by firewall rules.so I could setup a VPN with the IP of the server in the Local Network instead of the LAN network? Would I specify that as 192.168.1.160/32 ?
-
You can use "Client Specific Overrides" to force specific IPs to one or more clients if your server do TLS/SSL-auth or set up an additional vpn server for that group.
Then you can control access by firewall rules.I found another thread of yours and I'm close to getting this working. https://forum.pfsense.org/index.php?topic=132098.0
I have remote VPN working and can get into my LAN. I've setup a CSO to give my user a static IP of 172.16.2.250 and created an alias to place in a rule in the openVPN tab to block everything but my plex server but it still has access to the entire LAN. I previous tried pass only to the plex server and it still allowed access to the entire LAN. Here are some screen shots, I hope you can help me figure out what I'm doing wrong. Thanks all your posts on this topic.
-
Does the CSO work? Does the client get the intended IP?
Show your OpenVPN firewall rules.
Have you assigned interfaces to your OpenVPN servers?
-
Does the CSO work? Does the client get the intended IP?
Show your OpenVPN firewall rules.
Have you assigned interfaces to your OpenVPN servers?
I think the CSO is working the status shows an IP of 172.16.2.250.
I have not assigned an interface to the openvpn server
-
Your block rule blocks only access to port 32400 to any hosts except Plex Server.
For your needs, you should split this in two rules. One which allow access from the client to Plex Server 32400 and a second next underneath to block any from this client.
-
Your block rule blocks only access to port 32400 to any hosts except Plex Server.
For your needs, you should split this in two rules. One which allow access from the client to Plex Server 32400 and a second next underneath to block any from this client.
Finally it's working. Thanks so much for your help. Any idea on how to give these VPN users access to the internet (WAN port)?
-
Had to believe but I can't connect to the VPN anymore. Didn't change anything. Left the house for a few and came back and it doesn't connect anymore. The openVPN logs show TLS Error: TLS handshake failed. Any idea how that happened and how to fix it?
-
The openVPN logs show TLS Error: TLS handshake failed. Any idea how that happened and how to fix it?
This error is mostly shown when the vpn server is unreachable.
Do you have a dynamic WAN address? So maybe it was changed.Finally it's working. Thanks so much for your help. Any idea on how to give these VPN users access to the internet (WAN port)?
You must set an outbound NAT rule for the OpenVPN tunnel network Firwall > NAT > Outbound
If it's in automatic mode change it to hybrid, save and add a new rule:
Interface: WAN
Source: <openvpn tunnel="" network="">All other options should stay at their defaults.</openvpn> -
This error is mostly shown when the vpn server is unreachable.
Do you have a dynamic WAN address? So maybe it was changed.I have DDNS setup already and it's green showing my current WAN IP. I reloaded the config that I saved just after It worked and it is working. No idea what I could have done to get it to stop connecting.
You must set an outbound NAT rule for the OpenVPN tunnel network Firwall > NAT > Outbound
If it's in automatic mode change it to hybrid, save and add a new rule:
Interface: WAN
Source: <openvpn tunnel="" network="">All other options should stay at their defaults.</openvpn>My openVPN tunnel is 172.16.2.0/24 I already had that in the outbound rules but gave it another try keeping it at the top. Web site started to load and then just would hang. Subsequent tries nothing happens.
-
You have to change the destination to any in the marked rule shown in the attachment below, if you haven't already done.
Also maybe the backflow traffic is miss-routed, since you're missing an interface for this vpn instance.
I would try to assign an interface to the vpn server. After that move the appropriate firewall rules to the newly added interface.
-
You have to change the destination to any in the marked rule shown in the attachment below, if you haven't already done.
Already done
Also maybe the backflow traffic is miss-routed, since you're missing an interface for this vpn instance.
I would try to assign an interface to the vpn server. After that move the appropriate firewall rules to the newly added interface.So move all 3 rules from openvpn interface to Plex2? Can I delete the 3 rules from the OpenVPN interface?
 -
Can I delete the 3 rules from the OpenVPN interface?
If you have assigned an interface to each vpn instance you will not need these rules any more.
-
Still can't get the internet when connected to the VPN. Also noticed some strange behavior. When I connect the VPN that has everything blocked but Plex I was initially able to connect to other servers on the network. If I tried again they were blocked. I dissconnected and connected again to capture the openVPN log. Clicking on Apple.com worked but then trying to click on something else on there site didn't work anymore.
Here is the openvpn log. Not sure why I got a disconnect in the log as I was still connected.Jun 25 08:34:25 openvpn 69407 MANAGEMENT: Client disconnected Jun 25 08:34:25 openvpn 69407 MANAGEMENT: CMD 'quit' Jun 25 08:34:25 openvpn 69407 MANAGEMENT: CMD 'status 2' Jun 25 08:34:25 openvpn 69407 MANAGEMENT: Client connected from /var/etc/openvpn/server4.sock Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 SENT CONTROL [Plex2XXXXX]: 'PUSH_REPLY,route 192.168.1.1 255.255.255.0,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,redirect-gateway def1,route-gateway 172.16.2.1,topology subnet,ping 10,ping-restart 60,redirect-gateway def1,ifconfig 172.16.2.250 255.255.255.255' (status=1) Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 send_push_reply(): safe_cap=940 Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 PUSH: Received control message: 'PUSH_REQUEST' Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 MULTI: primary virtual IP for Plex2XXXXX/174.205.5.233:5225: 172.16.2.250 Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 MULTI: Learn: 172.16.2.250 -> Plex2XXXXX/174.205.5.233:5225 Jun 25 08:34:04 openvpn 69407 Plex2XXXXX/174.205.5.233:5225 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn-csc/server4/Plex2XXXXX Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 [Plex2XXXXX] Peer Connection Initiated with [AF_INET]174.205.5.233:5225 Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 VERIFY OK: depth=0, C=XX, ST=XXXXXX, L=XXXXXX, O=XXXXXX, emailAddress=xxxxx@gmail.com, CN=Plex2xxx Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 VERIFY SCRIPT OK: depth=0, C=XX, ST=XXXXXX, L=XXXXXX, O=XXXXXX, emailAddress=xxxxx@gmail.com, CN=Plex2xxx Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 VERIFY OK: depth=1, C=XX, ST=XXXXXX, L=XXXXXX, O=XXXXXX, emailAddress=xxxxx@gmail.com, CN=plex2-ca Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 VERIFY SCRIPT OK: depth=1, C=XX, ST=XXXXXX, L=XXXXXX, O=XXXXXX, emailAddress=xxxxx@gmail.com, CN=plex2-ca Jun 25 08:34:04 openvpn 69407 174.205.5.233:5225 TLS: Initial packet from [AF_INET]174.205.5.233:5225, sid=39a3b26a 88f230c3Here are the current rules and outbound just to be clear.
-
Any other ideas on how to get internet access when connected on the VPN? Do you need any further information?
-
You've set up an "IPv4 Local network" and then you've checked "Redirect gateway". Maybe this interferes.
To remove the local network uncheck "Redirect gateway" to get the option displayed, then remove the entry and re-check redirect gateway again.
-
You've set up an "IPv4 Local network" and then you've checked "Redirect gateway". Maybe this interferes.
To remove the local network uncheck "Redirect gateway" to get the option displayed, then remove the entry and re-check redirect gateway again.
Still can't access the internet when the VPN is turned on after following your instructions above. Is there anything else I could show you to help diagnose the problem?
-
Plex2 cannot access the internet since you've blocked it in the rules.
To get internet access change your block rule so that only your internal networks are blocked.
Best practice is to add an alias for all RFC 1918 networks (assume you use solely private networks) and use this in the rule.
Firewall > Aliases > IP
Name: RFC1918
Type: networks
Add:
192.168.0.0/16
172.16.0.0/12
10.0.0.0/8Then edit your block rule on PLEX2 and enter the RFC1918 alias at destination. Also you should change the protocol to any. So only any access to private IPs will be blocked.
-
Plex2 cannot access the internet since you've blocked it in the rules.
I disable the block rule in my plex2 interface and reset the states. I still can't get to the internet with the VPN on. If the block rule was the issue shouldn't it work with the rule disabled?
-
Yes, if you still get no access after disabling the block rule it couldn't be the cause.
Check the firewall logs for hints what's blocking the access.
In the log settings you can find the option "Where to show rule descriptions". Here you can set how the rule name is displayed to get an idea which rule is responsible for the log entry.
Also ensure that the "Log firewall default blocks" options are checked.
And in the firewall rules you should enable logging. Also consider floating rules. -
I've been trying to figure this out for a while. I've added to the client.opvn "redirect-gateway def1". In the status firewall logs when I try to access a web site it creates a default block on the WAN port. I guessing this means there was no rule above it that allowed the traffic to pass thru the WAN. My head is spinning. Is it correct that any rules I create to pass this traffic should be the 172.16.2.0/24 Virtual address vs the Real Address listed on the openvpn status page?
-
In the status firewall logs when I try to access a web site it creates a default block on the WAN port. I guessing this means there was no rule above it that allowed the traffic to pass thru the WAN.
Yes, that's it means. But the log entries which matter here are on the PLEX2 interface not on WAN.
You may use the filter option in the GUI to get less noise.Is it correct that any rules I create to pass this traffic should be the 172.16.2.0/24 Virtual address vs the Real Address listed on the openvpn status page?
Yes, the source address is the clients tunnel IP.
-
I disabled all the block rules on the WAN, Plex2, and OpenVPN interfaces including Bogons and RFC 1918 networks but still can't access the internet with the VPN on. Am I correct that it must not be a blocked problem. I'm missing a pass command for the traffic?
-
Are the routes on the client set correctly?
Please post the clients routing table. -
Are the routes on the client set correctly?
Please post the clients routing table.Here is the output of the diagnostic/routes :opvns4 is the Plex2 VPN
IPv4 Routes Destination Gateway Flags Use Mtu Netif Expire 0.0.0.0/1 172.21.92.1 UGS 137 1500 ovpnc1 default x.x.x.1 UGS 18 1500 em3 81.171.110.67/32 x.x.x.1 UGS 169422 1500 em3 x.x.x.0/24 link#4 U 99628 1500 em3 x.x.x.x link#4 UHS 0 16384 lo0 127.0.0.1 link#9 UH 676122 16384 lo0 128.0.0.0/1 172.21.92.1 UGS 18201 1500 ovpnc1 172.16.2.0/24 172.16.2.2 UGS 5139 1500 ovpns4 172.16.2.1 link#14 UHS 199412 16384 lo0 172.16.2.2 link#14 UH 0 1500 ovpns4 172.21.92.0/23 172.21.92.1 UGS 0 1500 ovpnc1 172.21.92.1 link#15 UH 99536 1500 ovpnc1 172.21.92.42 link#15 UHS 0 16384 lo0 192.168.0.0/24 link#3 U 0 1500 em2 192.168.0.1 link#3 UHS 0 16384 lo0 192.168.1.0/24 link#1 U 32974135 1500 em0 192.168.1.1 link#1 UHS 0 16384 lo0 192.168.10.0/24 link#10 U 0 1500 em2_vlan10 192.168.10.1 link#10 UHS 0 16384 lo0 192.168.20.0/24 link#11 U 0 1500 em2_vlan20 192.168.20.1 link#11 UHS 0 16384 lo0 192.168.30.0/24 link#12 U 0 1500 em2_vlan30 192.168.30.1 link#12 UHS 0 16384 lo0 192.168.40.0/24 link#13 U 0 1500 em2_vlan40 192.168.40.1 link#13 UHS 0 16384 lo0 192.168.60.0/24 link#2 U 35513 1500 em1 192.168.60.1 link#2 UHS 0 16384 lo0and the openvpn status routing table
 -
I asked for the routing table of the clients computer.
-
Sorry. I use my iphone. Any tips on how to get it from the openvpn app?
-
Don't know.
Check if you're able to access a public hosts by its IP address. Maybe the iPhone just can't access the DNS while vpn is connected.
On pfSense you can do packet capture (Diagnostic menu) while you're trying to access a internet IP to check if the traffic is routed over the vpn.
To do so, select the PLEX2 interface, to avoid noise you can select a particular protocol and port. At host enter the destination IP and start the capture. Then try to access the destination IP with the iphon. Stop the capture to see the result.
If you can see packets, select the WAN interface and repeat the capture.
Post the results, please. -
Check if you're able to access a public hosts by its IP address. Maybe the iPhone just can't access the DNS while vpn is connected.
https://81.171.110.67/ is the IP that is in the packet capture and I can't get to that site on my windows browser (nothing happens). Googling apple.com IP gives https://81.171.110.52/
which also doesn't connect but apple.com does. On iPhone I get forbidden error, you do not have permission to access this serverOn pfSense you can do packet capture (Diagnostic menu) while you're trying to access a internet IP to check if the traffic is routed over the vpn.
To do so, select the PLEX2 interface, to avoid noise you can select a particular protocol and port. At host enter the destination IP and start the capture. Then try to access the destination IP with the iphon. Stop the capture to see the result.
If you can see packets, select the WAN interface and repeat the capture.
Post the results, please.WAN IP capture
15:48:34.274662 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 177 15:48:34.275654 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 113 15:48:34.275693 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 209 15:48:34.275717 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 273 15:48:34.283405 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 113 15:48:34.283528 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 129 15:48:34.283737 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:34.283781 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 609 15:48:34.291524 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:34.292272 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 257 15:48:34.292602 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 161 15:48:34.293847 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 161 15:48:34.293875 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 161 15:48:34.293904 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:34.297145 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 241 15:48:34.298144 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 177 15:48:34.298473 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:34.302017 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:34.302025 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 145 15:48:34.322702 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:34.342695 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:34.345616 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:34.452554 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:34.456553 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:34.953592 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:34.960886 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:35.454624 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:35.461223 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:35.960584 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:35.965556 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:36.461627 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:36.465892 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:36.895894 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 129 15:48:36.922474 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:36.962547 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:36.970350 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:37.464638 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:37.470561 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:37.966576 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:37.971022 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:38.468652 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:38.474981 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:38.969589 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:38.973443 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 129 15:48:38.973790 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:38.976065 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:38.986435 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:39.470586 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:39.475903 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:39.972605 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:39.980111 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:40.203479 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 353 15:48:40.203510 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.209728 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:40.209852 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 145 15:48:40.250434 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:40.365267 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 689 15:48:40.365275 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 145 15:48:40.365611 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:40.473600 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:40.480572 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:40.578933 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.578950 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.578965 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.578980 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.586261 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 161 15:48:40.586506 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.587884 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:40.588119 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.637106 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:40.647512 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.647559 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.656345 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 161 15:48:40.674960 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 177 15:48:40.679560 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.730177 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:40.737581 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.737631 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.746043 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 161 15:48:40.786647 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 161 15:48:40.786811 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.821500 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 177 15:48:40.821640 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:40.826996 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 145 15:48:40.846111 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:40.855365 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:40.862065 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:40.874189 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 129 15:48:40.874248 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 113 15:48:40.892584 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 177 15:48:40.895565 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:40.924940 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:40.975709 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:40.981283 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:41.004573 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 145 15:48:41.067360 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:41.097216 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 225 15:48:41.476634 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97 15:48:41.481368 IP 81.171.110.67.1194 > x.x.x.x.30054: UDP, length 97 15:48:41.977559 IP x.x.x.x.30054 > 81.171.110.67.1194: UDP, length 97Plex2 Capture Host address gives nothing without it gives
16:04:02.925538 IP 172.16.2.248.55794 > 192.168.1.149.80: tcp 0 16:04:03.901359 IP 172.16.2.248.55794 > 192.168.1.149.80: tcp 0 16:04:04.909655 IP 172.16.2.248.55794 > 192.168.1.149.80: tcp 0 16:04:05.781252 IP 172.16.2.248.55376 > 208.67.222.222.53: UDP, length 42 16:04:05.933556 IP 172.16.2.248.55794 > 192.168.1.149.80: tcp 0 16:04:07.790472 IP 172.16.2.248.55376 > 208.67.222.222.53: UDP, length 42 16:04:11.782673 IP 172.16.2.248.55376 > 208.67.220.220.53: UDP, length 42Why is 81.171.110.67.1194 on my WAN and not 81.171.110.67.1195 as my VPN sever in on port 1195?
My settings for Plex2 Capture
 -
https://81.171.110.67/ is the IP that is in the packet capture and I can't get to that site on my windows browser (nothing happens). Googling apple.com IP gives https://81.171.110.52/
which also doesn't connect but apple.com does. On iPhone I get forbidden error, you do not have permission to access this server???
Resolving apple.com gives me 17.142.160.59
81.171.110.67 seems to be your own public IP. The WAN capture shows a connection to port 1194.
You're running multiple vpn servers. So this might be a connection to another server.This capture is cannot help to resolve the issue in any way.
-
I have a VPN client running to change my IP address. Didn't recognize the IP address. If I turn off the VPN client I can access the internet while connected to the remote VPN server. Is it possible to run the VPN Client and Remote VPN server and still access the internet? Sorry for the confusion I didn't realize it was an issue.
-
Yes, that's possible. But you've to clarify how the upstream traffic from PLEX2 should be routed out. To the VPN server or to the WAN gateway.
Now, since you haven't specified a gateway in the firewall rule, the traffic is routed to the vpn server. But since you haven't set an outbound NAT rule for this, you get no connection. -
Yes, that's possible. But you've to clarify how the upstream traffic from PLEX2 should be routed out. To the VPN server or to the WAN gateway.
Now, since you haven't specified a gateway in the firewall rule, the traffic is routed to the vpn server. But since you haven't set an outbound NAT rule for this, you get no connection.Thanks for hanging in there with me.
I created a rule on the PLEX2 interface, source =any, dst =any, and Gateway = WAN_DHCP Gateway then
Outbound rule- PLEX2 interface, protocol any, network 172.16.2.0/24, dst any, translation Interface Address.
Rebooted and doesn't work. Any idea on what I did incorrectly? -
Man, Outbound NAT rules have to be set on that interface where the packets go out!
So if you want to go out on WAN the interface has to be set to WAN.
The necessary rule was already set as shown in this post: https://forum.pfsense.org/index.php?topic=132341.msg729392#msg729392 -
Man, Outbound NAT rules have to be set on that interface where the packets go out!
So if you want to go out on WAN the interface has to be set to WAN.
The necessary rule was already set as shown in this post: https://forum.pfsense.org/index.php?topic=132341.msg729392#msg729392I have everything setup with the Plex2 rule having the WAN gateway but still packet capture still show trying to go out the 1194 client VPN instead of the WAN gateway. I even changed all 3 Plex2 rules to use the WAN gateway without success. If the WAN gateway is the default and the rule is set to use the default why does it need to be specified?
-
I've wrote above that you've to clarify where you want to route out the upstream traffic from PLEX2 client. If you haven't specified a gateway, the traffic is routed to the default gateway and this is obviously the vpn client if it's connected. So the packets are routed to the vpn client, but in fact you've no outbound NAT rule that, so the packets get dropped there, cause there is no route back for that source.
If you want the traffic route out to WAN while the vpn client is the default gateway, you've to specify the WAN gateway in the rule.
If you want to go out to the default gateway there's no need to specify a gateway in the rule, but you've to add an outbound NAT rule for that. -
I've wrote above that you've to clarify where you want to route out the upstream traffic from PLEX2 client. If you haven't specified a gateway, the traffic is routed to the default gateway and this is obviously the vpn client if it's connected. So the packets are routed to the vpn client, but in fact you've no outbound NAT rule that, so the packets get dropped there, cause there is no route back for that source.
If you want the traffic route out to WAN while the vpn client is the default gateway, you've to specify the WAN gateway in the rule.
If you want to go out to the default gateway there's no need to specify a gateway in the rule, but you've to add an outbound NAT rule for that.- I have specified the WAN gateway in the PLEX2 rule so have I satisfied the "you've to specify the WAN gateway in the rule"?
- If I have satisfied #1 then the problem is not specifying a outbound NAT rule. Can you give me an example of outbound rule that would work? There are not many options after Interface, Source address. Interface must be WAN, the Source is my 172.16.2.0/24 the VPN tunnel network, destination is any as it could be anywhere on the internet.
-
- I have specified the WAN gateway in the PLEX2 rule so have I satisfied the "you've to specify the WAN gateway in the rule"?
If you intend, that PLEX2 upstream traffic goes out on the WAN interface independently from the vpn client connection, that's okay.
- If I have satisfied #1 then the problem is not specifying a outbound NAT rule. Can you give me an example of outbound rule that would work? There are not many options after Interface, Source address. Interface must be WAN, the Source is my 172.16.2.0/24 the VPN tunnel network, destination is any as it could be anywhere on the internet.
Again, you've already set an outbound NAT rule for PLEX2 on WAN interface. The first rule shown in the picture here: https://forum.pfsense.org/index.php?topic=132341.msg729392#msg729392
Outbound NAT:
When a packet go out to WAN, the packets source address has to be translated to one of your public addresses, mostly the WAN (interface) address. Cause only public addresses are known in the internet, which is necessary to route back the responses to you.
So you have to set in the rule:
interface: WAN
source: here the tunnel subnet 172.16.2.0/24
All other options may be stay on their defaults. So the protocol and destination is any and the translation address is "interface address" which is your WAN address.Is this really as hard?
-
I have the outbound rule as, Intereface WAN, source 172.16.2.0/24 all other options at default.
If I have a rule on the Plex2 interface, source any, destination any, gateway default I can access my local LAN servers but not the internet. If I change the default gateway to the WAN I can access the internet but not any of the LAN servers.