Help VPS Openvpn 4G

[s00999]

Hi,

I've setup a VPS in order to access my IPCAM from web.
My pfsense is connected trough a openvpn client to the VPS server. Obtain IP 10.255.201.14

On the VPS, I've open and redirect the port 10501 to ip 10.255.201.14

On the pfsense, I've created the following port forward rules :

But can't get access to my cam.

I capture a tcp dump and here is the result

On the pfsense firewall, it seems that the paquet is well redeirected to my ipcam IP

From here I'm stuck .

Thanks a lot for your help

[viragomann]

@s00999
Check out if the cam is accessible from other network segments at all.

[s00999]

@viragomann From LAN no problem to access the webcam

[viragomann]

@s00999
Ok, the first challenge is taken. Some cams are not able to be accessed from other networks.

As your NAT screenshot shows, you have already assigned an interface to the OpenVPN client instance.
Add a firewall rule to this interface to allow the incoming connection and remove all pass rules from the OpenVPN tab if you don't need it for other purposes. Also ensure that there is no floating pass rule mathing that traffic. If you need them come back.

[s00999]

@viragomann Hi,

I disable the rule in the OpenVPN tab and add the rule in the OpenVPNclient instance tab.

The port is now open when I check on portchecker.co and I can access my CAM web interface.

As soon as I reactivate the rule in the OpenVpn tab, it's stop working. Can you explain me why?

I have another openvpn client in used. is removing rules in openvpn tab will cause issues?

Thanks

[viragomann]

@s00999
There must no pass rule on the OpenVPN tab match the incoming traffic you've forwarded from the remote site. I wrote that in bold letters due to a good reason.

You've forwarded public source IPs from remote. However, by default replies goes out to the default gateway which is WAN in your case.
For sending replies back to the correct interface, pfSense marks request packets which are coming in from a gateway (the remote VPN server) with the reply-to flag which includes the gateway. This is done by the filter rule which allows the packet to pass. However, that requires that the interface has to be unique in the rule.
But the OpenVPN tab is an interface group, including all OpenVPN instances running on pfSense, and interface group rules are processed before rules on member interfaces. Hence if a rule on OpenVPN matches pfSense doesn't add the reply-to and consequently replies are send out to WAN.

So if you are running other OpenVPN instances, simply assign also an interface to them and add you needed rules there.
But you can also change the OpenVPN interface rules so that the don't match the packets from the VPS. E.g. if your access servers tunnel is 10.0.8.0/24 you can use this tunnel network as source and it won't match to the other connections.

[s00999]

@viragomann said in Help VPS Openvpn 4G:

m and add you needed rules there.
But you can also change the OpenVPN interface rules so that the don't match the packets from the VPS. E.g. if your access servers tunnel is 10.0.8.0/24 you can use this tunnel network as source and it won't match to the other connections.

Thanks for the complément of information.

When I look at the logs, the source paquet is always the public IP of the device that try to connect to the CAM. I don't see the IP corresponding to my VPN tunnel.

So how can I specified a source IP for each of my openvpn client interface?

[viragomann]

@s00999 said in Help VPS Openvpn 4G:

When I look at the logs, the source paquet is always the public IP of the device that try to connect to the CAM. I don't see the IP corresponding to my VPN tunnel.

I was talking about your access servers tunnel network.

As soon as I reactivate the rule in the OpenVpn tab, it's stop working.

That you have already a rule on the OpenVPN tab let me assume, that you've fired up an access server.
So the source address in the OpenVPN rule might be any. Now edit this rule and set the source to the access server tunnel network.
Consequently this rule will not longer affect the incoming connection from the remote site, since these packets have a public source IP.

[s00999]

@viragomann

Thanks for your help.

Everything works like a charm now.