Port Forwarding OVPN
-
Well sure looks like your getting answer - most likely RST!
Why don't you open that packet capture up in an say wireshark ant take a look see. Or have it give you more verbosity.. Would bet money those answers your 192.168.0.233 box is sending is RST... Or in other layman words - F Off!!
It's going to be more informative to open the capture up in pfsense. But clearly pfsense sent traffic on to the .233 box.. So your forward worked.
-
@johnpoz said in Port Forwarding OVPN:
Well sure looks like your getting answer - most likely RST!
Why don't you open that packet capture up in an say wireshark ant take a look see. Or have it give you more verbosity.. Would bet money those answers your 192.168.0.233 box is sending is RST... Or in other layman words - F Off!!
It's going to be more informative to open the capture up in pfsense. But clearly pfsense sent traffic on to the .233 box.. So your forward worked.
13:37:28.851431 IP 198.199.98.246.32906 > 192.168.0.226.60720: tcp 0 13:37:28.851947 IP 192.168.0.226.60720 > 198.199.98.246.32906: tcp 0 13:37:29.848971 IP 198.199.98.246.32906 > 192.168.0.226.60720: tcp 0 13:37:29.859111 IP 198.199.98.246.32908 > 192.168.0.226.60720: tcp 0 13:37:29.859613 IP 192.168.0.226.60720 > 198.199.98.246.32908: tcp 0 13:37:30.855759 IP 198.199.98.246.32908 > 192.168.0.226.60720: tcp 0 13:37:30.858247 IP 198.199.98.246.32911 > 192.168.0.226.60720: tcp 0 13:37:30.858606 IP 192.168.0.226.60720 > 198.199.98.246.32911: tcp 0 13:37:31.852423 IP 192.168.0.226.60720 > 198.199.98.246.32906: tcp 0 13:37:31.857319 IP 198.199.98.246.32911 > 192.168.0.226.60720: tcp 0 13:37:32.853667 IP 192.168.0.226.60720 > 198.199.98.246.32908: tcp 0 13:37:33.855741 IP 192.168.0.226.60720 > 198.199.98.246.32911: tcp 0
Come on, I had changed the ip address of my other server to see if it works there but now I have changed the ip address of 192.168.0.226 to other server running iperf3.
At yougetsignal.com it still says that the gate is closed.
-
Well looks like your server is sending syn,ack back.. But doesn't seem to be getting back to the sender of the syn.
Sniff on the openvpn interface - do you see the syn,ack going back up the tunnel.. If so then its on your vpn.. Need to make sure the syn,ack is not going back out the normal wan vs the vpn tunnel.
-
@johnpoz said in Port Forwarding OVPN:
Well looks like your server is sending syn,ack back.. But doesn't seem to be getting back to the sender of the syn.
Sniff on the openvpn interface - do you see the syn,ack going back up the tunnel.. If so then its on your vpn.. Need to make sure the syn,ack is not going back out the normal wan vs the vpn tunnel.
Interface OVPN_VPN
14:03:27.864349 IP 198.199.98.246.39458 > 10.128.56.178.60720: tcp 0 14:03:28.861481 IP 198.199.98.246.39458 > 10.128.56.178.60720: tcp 0 14:03:28.862139 IP 198.199.98.246.39465 > 10.128.56.178.60720: tcp 0 14:03:29.862138 IP 198.199.98.246.39465 > 10.128.56.178.60720: tcp 0 14:03:29.868060 IP 198.199.98.246.39471 > 10.128.56.178.60720: tcp 0 14:03:30.866820 IP 198.199.98.246.39471 > 10.128.56.178.60720: tcp 0
So it receives packages but sends it back in LAN instead of VPN if I get it right?
Edit:
WAN
14:40:08.600178 IP 10.128.56.178.60720 > 198.199.98.246.49340: tcp 0 14:40:09.611224 IP 10.128.56.178.60720 > 198.199.98.246.49345: tcp 0 14:40:10.614437 IP 10.128.56.178.60720 > 198.199.98.246.49350: tcp 0 14:40:11.609323 IP 10.128.56.178.60720 > 198.199.98.246.49340: tcp 0 14:40:12.604408 IP 10.128.56.178.60720 > 198.199.98.246.49345: tcp 0 14:40:13.625117 IP 10.128.56.178.60720 > 198.199.98.246.49350: tcp 0 -
Seems to be the same problem I had, the return traffic is going out over WAN and not over the VPN tunnel. You should not see that traffic on the WAN interface, you should see UDP packets over port 1194.
I guess you'll need to do source based routing to make this traffic return over the vpn tunnel also.
Check so you have no rules in the openvpn tab on firewall, could be it because it will look at those rules first.
-
@kroem said in Port Forwarding OVPN:
Seems to be the same problem I had, the return traffic is going out over WAN and not over the VPN tunnel. You should not see that traffic on the WAN interface, you should see UDP packets over port 1194.
I guess you'll need to do source based routing to make this traffic return over the vpn tunnel also.
Check so you have no rules in the openvpn tab on firewall, could be it because it will look at those rules first.Agreed. You'll want to verify several things:
-
Verify the port is forwarded on the front end (according to your rules, it looks to be either PIA or OVPN). Since traffic appears to be making it to your firewall, we can presume this is done, but I always check regardless.
-
Verify traffic sourced from the host's IP is routed down the tunnel via policy routing. If we assume your host's IP is part of the "pia_redirect_group" alias then we're good here also, but I would double check to be sure.
-
Verify there is an outbound NAT for traffic sourced from your host's IP (or subnet) on the PIA/OVPN interface
-
Verify your port forwards are configured on the correct interface and have the correct destination (PIA/OVPN interface and destination)
-
Verify traffic is not being matched on the wrong interface. In other words, the rules on your OpenVPN tab should be explicit and not the default any/any. In other words, any rules on the OpenVPN tab should have an explicit source and destination or traffic will get sent out the wrong interface and will break port forwarding
-
-
@sweden_cool said in Port Forwarding OVPN:
14:40:08.600178 IP 10.128.56.178.60720 > 198.199.98.246.49340: tcp 0
So that is going out your WAN... Yeah that never going to work..
-
The incoming traffic MUST NOT match rules on your OpenVPN tab.
The incoming traffic MUST match rules on your assigned interface tab.
You showed the rules on OVPN_VPN but not OpenVPN. If the traffic matches on the OpenVPN tab you WILL NOT get reply-to on the states and reply traffic will route according to the routing table, which likely means it will go out to the default gateway on WAN.
-
Ok, I fired up a new OVPN connection and got this working ( I got stuck about a year ago and decided to just move all VPN "protected" hosts under another virtual FW ). Not sure where I failed earlier.
Anyways. This works, the test interfaces I used where "LAN" and "VPN_OVPN_US"
fw-rules needed:
one pass rule on your LAN interface matching the hosts you want to use VPN, and set OVPN_INTERFACE_VPNV4 (or something) as gateway. Make sure this rule is matched before a "allow any out on LAN" rule for instance, otherwise it will not even be looked at. (i.e. but this rule at the top...)
Something like this works ( I just had one source for my test 10.1.1.199)Protocol Source Port Destination Port Gateway IPv4 * 10.1.1.199 * * * VPN_OVPN_US_VPNV4one pass rule created by your port forwarding rule, to match any traffic on VPN_OVPN_US interface and allow traffic to the port forwarded host and port. ie:
Protocol Source Port Destination Port Gateway IPv4 TCP/UDP * * 10.1.1.199 59362 *NAT rules needed:
You need to have the port forwarding rule, which created the fw-rule above
Interface Protocol Source Address Source Ports Dest. Address Dest. Ports NAT IP NAT Ports VPN_OVPN_US TCP/UDP * * VPN_OVPN_US address 59362 10.1.1.199 59362And you need to have an outbound NAT (use Manual Outbound NAT rule generation) rule to translate the traffic back over the VPN tunnel:
Interface Source Source Port Destination Destination Port NAT Address VPN_OVPN_US 10.1.1.199/32 * * * VPN_OVPN_US address *This works for me just to get routing working, then you might need to secure it etc, but routing works when I start a iperf server and connect to it from Internet.
Try it out ...
-
@kroem said in Port Forwarding OVPN:
Ok, I fired up a new OVPN connection and got this working ( I got stuck about a year ago and decided to just move all VPN "protected" hosts under another virtual FW ). Not sure where I failed earlier.
Anyways. This works, the test interfaces I used where "LAN" and "VPN_OVPN_US"
fw-rules needed:
one pass rule on your LAN interface matching the hosts you want to use VPN, and set OVPN_INTERFACE_VPNV4 (or something) as gateway. Make sure this rule is matched before a "allow any out on LAN" rule for instance, otherwise it will not even be looked at. (i.e. but this rule at the top...)
Something like this works ( I just had one source for my test 10.1.1.199)Protocol Source Port Destination Port Gateway IPv4 * 10.1.1.199 * * * VPN_OVPN_US_VPNV4one pass rule created by your port forwarding rule, to match any traffic on VPN_OVPN_US interface and allow traffic to the port forwarded host and port. ie:
Protocol Source Port Destination Port Gateway
IPv4 TCP/UDP * * 10.1.1.199 59362 *NAT rules needed:
You need to have the port forwarding rule, which created the fw-rule above
Interface Protocol Source Address Source Ports Dest. Address Dest. Ports NAT IP NAT Ports
VPN_OVPN_US TCP/UDP * * VPN_OVPN_US address 59362 10.1.1.199 59362And you need to have an outbound NAT (use Manual Outbound NAT rule generation) rule to translate the traffic back over the VPN tunnel:
Interface Source Source Port Destination Destination Port NAT Address VPN_OVPN_US 10.1.1.199/32 * * * VPN_OVPN_US address *This works for me just to get routing working, then you might need to secure it etc, but routing works when I start a iperf server and connect to it from Internet.
Try it out ...
Do you need everyone or can you remove two of them?
-
@sweden_cool said in Port Forwarding OVPN:
Do you need everyone or can you remove two of them?
You can remove the ISAKMP one. I'm not sure about the "pia group" one, but I guess that's from some tutorial ? Remove it or disable it. Keep it clean.
