Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access

slu

@Unoptanio
dou you have set firewall rules for the OpenVPN connection?

Unoptanio

@slu
the openvpn wizard entered them automatically

slu

@Unoptanio said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

the openvpn wizard entered them automatically

no I mean internet access from your VPN client over the VPN into WAN.
That was your question, or?

Gertjan

@Unoptanio

Observe :

As soon as you connect, the right number will raise.
The left number will show the number of open states, so bigger then 0.

This means traffic comes in ....
Do you see the same ?
To hit your perfect OpenVPN server Firewall rules :

as these are all pass rules (for me : IPv4 and Ipv6) traffic can get everywhere.
Take note : the counter in front of the rules : do they go up ?

If you were connecting to some device on LAN, then the traffic would get routed out to the LAN interface, and then it really try to reach that device ....
Suspense : will this device (its firewall ?) accept this traffic

You can do a packet capturing on the LAN interface, as you know the destination IP, and destination port, and protocol used (UDP ?)
Do you see it ?

Unoptanio

@Gertjan

latest updates and tests:
I added a specific OPEN_VPN interface that I didn't have before

here the numbers turn, there is traffic when there are rdp sessions

The problem:
RDP work only with IP address of the pc
if i use PC name not working

Gertjan

@Unoptanio said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

I added a specific OPEN_VPN interface that I didn't have before

This Open_VPN is assigned to the OpenVPN server instance ?

Like this (my OpenVPN server ) :

?

Then you have probably an issue.
RDP is mostly, if not all, UDP based. Your firewall rule only permits IPv4-TCP and blocks IPv4-UDP.

As proposed : time to do some : Diagnostics > Packet Capture

Btw : read also : Cannot connect with RDP via openVPN for some out of the box thinking ;)

Unoptanio

This post is deleted!

Unoptanio

@Gertjan said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

s unbound also listens on 10.10.94.1, the OpenVPN server IP on the pfSense side.

Why ? Now

@Gertjan said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

Why ? Now you can use local URL/host names like server.XXXXpfSense.homa.arpa to join a RDP session on "server" on your LAN.
8.8.8.8 and others don't know anything about your local devices ;)

I finally found it. it's about DNS resolver at the bottom

you need to add the hostnames in the override section of the DNS resolver.
This way you can access RDP using hostname.domain

Tried it works

Unoptanio

@Gertjan
Good morning, excuse me , in the openvpn log section I find these IP addresses unknown to me that are trying something.

Do I have to worry?
What I can do?

Gertjan

@Unoptanio said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

Do I have to worry?

Noop.
Example : you have a phone, and a SIM card. So you have a phone number.
Is is a surprise that very body on earth can call you right now ? Of course not. That's the way it should work.
( although there are people that actually want to use world's public phone network but not want to be called by any one .... or drive on the public road, and not want to encounter other people with their cars - you understand what I mean )

Before, they had this perfect WAN firewall rule set :

Yep, that is right : no rules !!
The default firewall behaviour is : drop everything that comes in.
And if you had this one not checked :

then you aren't even aware that there are actually incoming connection all the time.
Like something pressing on your doorbell, and even trying if the front door is open .... They try without stopping.

Now that your pfSense has a process that is actually listening on the WAN interface, (port 1194, protocol UDP), you suddenly can see them .....
Nothing changed. You just became aware of this aspect. It was always there already.

So nothing to worry about. It's part of becoming more "aware". Just keep on doing this ^;)

@Unoptanio said in Pfsesne 2.7.0 OpenVPN Client connected, RDP Work OK BUT no internet access:

What I can do?

Although I should not advising anybody to stop securing is infrastructure, I can tell you this :
I do nothing.
I have this rule :

like you.
And if some one manages to 'pass along' the OpenVPN (the process listing) then I kneel down and will say : "I'm honoured to meet you". OpenVPN-server as of today, hasn't been broken yet.
When the entire planet went into a lock down and home working became the new thing, every company was implementing a OpenVPN access.
And noop ..... OpenVPN wasn't broken ....

So : again : let them have it.

You can, of course, do something about it.

Stupid, but valid example :

You saw the Source (IP) is a start which means : all the IPv4, so from 0.0.0.0 to 255.255.255.255.
You can change that.
Put an alias in place !
And set this alias to the IPv4 of your phone or device you use to connect to your OpenVPN server.

Now only you - your device - can connect to your OpenVPN.
And nobody else.

You'll find out quickly that you can't control what IPv4 your device is using while running around in your country.
So : note down the IPv4 - and call home, and have the alias used in the OpenVPN set to this IPv4.
Now you can connect again, using any IP.
And no one else.

You'll say : hey, that's tedious ! Of course it is. So, automate it !
Example use some dyndns client on your phone or PC. When it conects to the Internet, it will update your "your-device.dydns.org" so it point to your device.

On the pfSense side of things, decalre an URL/IP as "your-device.dydns.org". pgSEne will no refresh the IP of this your-device.dydns.org every 5 minutes or so (check this !).

So, your device gets an IPv4 - it will update it, and max 5 minutes later, the pfSense alias is 'resolved' and you can 'OpenVPN' into your pfSense as only that IP is now valid.

Btw : I just invented this procedure, I never actually tested and used it.