Cannot connect with RDP via openVPN
-
Yep, looks fine, traffic comes into the OpenVPN interfaces, go to the OpenVPN server.
@IrixOS said in Cannot connect with RDP via openVPN:
All RDP settings on the windows servers are OK.
Like : the server/PC on which RDP runs, accepts connection form the OpenVPN interface - which is not the LAN network ?
-
No there is a default 0 route pointing to the pfsense box, and routes back to the switch. This setup has always worked.
I have a VDSL2+ modem bridged with the pfsense. The pfsense box is connected with the cisco L3 switch and that router/switch is connected to a L2 distribution switch which connects to the rest of the access switches.
From the inside network I can RDP no problem.Also noticed that I cannot access the pfsense webpage from the openVPN client on the smartphone. This exact setup has worked before you know. Nothing has changed since then. It's bizar.
I can ping everything from the openVPN client on the smartphone but RDP does not work. I can hardly believe there is something with the VPN routing itself, I don't know.To my opinion the fact I cannot access the pfsense webpage and cannot RDP makes the VPN connection useless. Such a shame.
Any findings would be appreciated.
Ask me anything you want to know to acquire a solution,Thank you,
-
That is the model setup. The default router representing pfsense.
-
@IrixOS Post your openvpn config (config.ovpn)
Post the rules on your OpenVPN tab
Verify your VM's are using your SVI's as the default gateway
Are you entering the hostname or the IP in the "Computer" box for RDP?
-
Could always provide a traceroute to confirm routing
-
Can you post : the startup openvpn log sequence of the OpenVPN server ?
and
The openvpn log at moment you (try to) connect to the OpenVPN server@IrixOS said in Cannot connect with RDP via openVPN:
Nothing has changed since then
Things can break over time. Like certificates become expired.
-
This post is deleted! -
VM's Checked SVI and default gateway, all ok, BTW, I can ping every machine from the openvpn app on the smartphone.
Tried both IP and DNS resolution, no connection
-
Are you having an MTU issue ??
Maybe try this
fragment 1400 mssfix 1400https://forum.netgate.com/topic/182605/solved-firewall-wan-blocking-packets-destined-for-a-working-openvpn
Remember to do it on both ends
/Bingo
-
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_VER=3.git::081bfebe:RelWithDebInfo
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_PLAT=android
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_NCP=2
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_TCPNL=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_PROTO=30
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_LZO_STUB=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_COMP_STUB=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_COMP_STUBv2=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_GUI_VER=net.openvpn.connect.android_3.3.4-9290
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_SSO=webauth,openurl,crtext
Sep 5 16:03:01 openvpn user 'kurkunv' authenticated
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1559'
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 [kurkunv] Peer Connection Initiated with [AF_INET]94.109.209.23:2845
Sep 5 16:03:01 openvpn 27362 kurkunv/94.109.209.23:2845 MULTI_sva: pool returned IPv4=172.16.1.2, IPv6=(Not enabled) -
persist-tun
persist-key
cipher AES-128-CBC
ncp-ciphers AES-256-GCM:AES-128-GCM
auth SHA1
tls-client
client
remote rshafw000000001.ddns.net 1194 udp
verify-x509-name "www.rsha.de" name
auth-user-pass
remote-cert-tls server
compress lz4-v2<ca>
-----BEGIN CERTIFICATE-----
MIIEZTCCA02gAwIBAgIBADANBgkqhkiG9w0BAQsFADB/MQswCQYDVQQGEwJCRTEQ
MA4GA1UECBMHQW50d2VycDEPMA0GA1UEBxMGRHVmZmVsMQ0wCwYDVQQKEwRSU0hB
MSgwJgYJKoZIhvcNAQkBFhl2b2xrYW4ua3Vya3VuQGhvdG1haWwuY29tMRQwEgYD
VQQDEwtpbnRlcm5hbC1jYTAeFw0xODA3MDExNzQ4MDlaFw0yODA2MjgxNzQ4MDla
MH8xCzAJBgNVBAYTAkJFMRAwDgYDVQQIEwdBbnR3ZXJwMQ8wDQYDVQQHEwZEdWZm
<snipped by mod>
aJjpXervXoYbqjMwiSOaaUcFgMqBngV120WYlmrhes7DdLGImFePGGMKC9VE7krZ
vGAiZe+nPEVjFoJTypc6+6NX12o4cfq3qg==
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIEvDCCA6SgAwIBAgIBAjANBgkqhkiG9w0BAQsFADB/MQswCQYDVQQGEwJCRTEQ
MA4GA1UECBMHQW50d2VycDEPMA0GA1UEBxMGRHVmZmVsMQ0wCwYDVQQKEwRSU0hB
MSgwJgYJKoZIhvcNAQkBFhl2b2xrYW4ua3Vya3VuQGhvdG1haWwuY29tMRQwEgYD
VQQDEwtpbnRlcm5hbC1jYTAeFw0xODA3MDExNzQ5MzhaFw0yODA2MjgxNzQ5Mzha
MHsxCzAJBgNVBAYTAkJFMRAwDgYDVQQIEwdBbnR3ZXJwMQ8wDQYDVQQHEwZEdWZm
ZWwxDTALBgNVBAoTBFJTSEExKDAmBgkqhkiG9w0BCQEWGXZvbGthbi5rdXJrdW5A
<snipped by mod>
jMS6LIf0YDcHlXxGff/chxVkidbKQoa8gMd0qf0UhtF3Qd4qHKK8rPjBF8cptckB
3WQTokQXuKTvtsWe+HFt9pdSqLOSs58jSEB+ZZfoMU7kScnFXJ1pgW1M7cHIVBqG
L1VCkJEcTKHvbGKNIlsHa/S/VoEME0EGn7MCh1F/hvK4hc80MxzU7p6MBBN+Z8Zm
4UNT4g6aTjsMYp5XzywdWMXBw5tuSx8lc9qhIPQf6+5B5sekC1WZPPOlAT2P1BF8
gZBKUNdYPGt+3vrChjaLY2pfrSxgk6N3w24T4OIUx6qwwH/5GgzDFhynww2uSa+V
eblidbXb9sAXqAJweCNNUg==
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC8tPHojOuy6ZHb
Y3KfN1Gh0bmHUa8qZxLO9UzcJBhq4Mr1Ml8UFSRNCZ2MszXLU9YGaDiA9RBFDRx/
HjYKKhfxFX2QrYdT61LFBpBUDkorTuuYJ1bPgDsV3IHbcOiE5Nk8vAqT8KAAh+vS
tgAO6RLH3Ncp15+nYmSrkeQECzAF3aOT9T8r1bqxSHFUojJKjPoQeZ62dIWD9Mxs
<snipped by mod>
tetslkmM3VGBiDsK8j5dfBQcPHc4Rt2kUFLjRQHmmiQDUuTGywuldkQ7Pw8Rl/xd
1IEp1x7ZLY1d4o68YPvYYL0m/u7/o4w28UP27v69mTtgnV5wGDnPofsoNQKBgFG1
7e7ULd3+XeZZMqzqL3caXtq7f3P725CXCauEeMpgxJBei77oFhb8tHdg62enxh6N
WsQj6DZmHOqtBhx+M26ud4VrJSpKZ+UrsVQ3R629ryv+Xu75CudrB2VIMM39Gp+r
zPrfOAk/VC/GZoStBj8SZEynVHPeAq/pdBknlUx1AoGAbxsocW68vmTVy/pHJdA6
MQxQKyp4rAARVTMRyhYZhaNcaie/Qmb2vdbrqIDJfCFlIICoqThi1j5zjFt1HvBk
x/Dprv6UspaoFWOGhicwGY0tRcx7lkGsehbVmgoynOkwlyQVMfPcu5C4ecXTnAVH
V7yNsaepx91mwVZRhL6qaJk=
-----END PRIVATE KEY-----
</key>
<tls-auth>2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
dd18a2ffe3bd789cd0f4287bde6a90ba
cfe34ea65521461d69582f82f9d30c59
c3fed75174b1bcf2fca5636854f9a896
<snipped by mod>
ab1ef19de29738094360a33e2fa9ed2e
9591ac77b0dc611ddd7a3ce9a5219dad
7fecdef9c325b80c3902820057d734ac
552493644a44c8719a85d26e35845ec1
c3e0e04b4365e7c47d5e757ed69d16a3
-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1 -
This is the log, how doe you change the MTU, I found a field on the WAN if tab, you said both ends, I will try to find the setting in openVPN client.
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_VER=3.git::081bfebe:RelWithDebInfo
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_PLAT=android
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_NCP=2
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_TCPNL=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_PROTO=30
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_LZO_STUB=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_COMP_STUB=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_COMP_STUBv2=1
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_GUI_VER=net.openvpn.connect.android_3.3.4-9290
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 peer info: IV_SSO=webauth,openurl,crtext
Sep 5 16:03:01 openvpn user 'kurkunv' authenticated
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1559'
Sep 5 16:03:01 openvpn 27362 94.109.209.23:2845 [kurkunv] Peer Connection Initiated with [AF_INET]94.109.209.23:2845
Sep 5 16:03:01 openvpn 27362 kurkunv/94.109.209.23:2845 MULTI_sva: pool returned IPv4=172.16.1.2, IPv6=(Not enabled) -
You set it in the openvpn client + server config windows - Advanced configurations window
See here for an example:
https://forum.netgate.com/topic/182605/solved-firewall-wan-blocking-packets-destined-for-a-working-openvpnDo it on the "remote first" , then the local .....
Aaaannnd it's always good to have https access to the box, if accessing/managing it via openvpn.
Edit: Looks like your listed client above is "Android" ....
If you used Client export , you can add the options there too , to be exported.
-
@IrixOS I snipped out some of that info - that is dangerous to post your full certs/keys on public forum..
-
-
@IrixOS
Just a question ...
You do have RDP enabled , and allowed in the WIN firewall ... Correct -
I'll complement this one :
@bingo600 said in Cannot connect with RDP via openVPN:and allowed in the WIN firewall
When you activate the RDP server process in your Microsoft OS, by default (as per Redmond's rules) only connections from the local LAN, like 192.168.1.1/24 (or whatever your LAN is) are accepted, as Microsoft doesn't want you to use RDP from 'everywhere' aka the Internet.
The protocol just isn't safe enough, it was written with speed in mind, not security.When you use a VPN connection, this isn't really an issue, as you control the entire connection, and the dangerous part is "secured" as it is running over OpenVPN.
So : go to the Windows firewall, and modify (easier, you will find it) it.
This is mine :
Two rules, as there is one for TCP and one for UDP.
Btw : Double check that your PC recognizes the LAN network as private, not public. In Public mode it will accept no connections - from no one.
I know : you said it was working before, so my words are actually useless.
Just double check ^^ (maybe if some one has reset the windows firewall recently ) -
@Gertjan said in Cannot connect with RDP via openVPN:
you said it was working before, so my words are actually useless.
Or maybe it changed from private to public.. But if that was the case you would think ping wouldn't work either, because if blocked ping would be blocked too, etc.
But yes checking the firewall rules on the PC for sure prudent..
If I was troubleshooting this problem, I would validate that the traffic is even being sent to the client.. So you know where to look - this would be as simple as sniffing for port 3389 on the lan side interface the pc is connected too.. So for example I just connected to vpn on my iphone.
setup a sniff on lan for 3389.. Then connected via my phone rdp client. Screen pops right up on my phone, and you can see from the sniff traffic flowing both ways. If download and open in wireshark - can see the syn, and then syn,ack response..
The 10.0.200.250 address is the address my iphone when it connects to the vpn.. I am using rd client on my phone
https://apps.apple.com/us/app/remote-desktop-mobile/id714464092
If your never seeing the traffic get sent to the PC IP, then you need to look upstream.. If you see traffic sent to the client IP, but no answers - then you have the wrong IP your trying to connect too? Its not running remote desktop? Its on a different port than the standard 3389, its running a firewall? Its not using pfsense as its gateway, etc. But the simple sniff would tell you where to look next, either in pfsense firewall rules, etc.. Or towards the client.
edit: other obvious indication of a connection from client started at least, was I saw my PC that using (which is one I rdp to from phone) screen go to the login screen..
-
How can I close the ticket on this forum?
I have to mothball everything. My distribution switch has failed. I can't believe this is happening right now! From the port LEDs I can see that the switch has a serious problem.
The console says SYSTEM INIT: NOT ENOUGH MEMORY TO BOOT
Pure nonsense!
The switch may be outdated but it's brand new, I've only turned that retarded thing on and off three times!
It's certainly not the first time!
The other one I bought also had a problem. All the LEDs are flashing but it won't boot.
I already tried heating the solder joints, and then the port LEDs all came on, but no console.
A dead fish in the water! How is that possible, that damn thing was brand new, never used, ever programmed!DAMN YOU CISCO!!!!!!!
PFSENSE sucks and CISCO sucks, I haven't touched that moronic thing for years. VPN has always worked! RDP has always worked! PERIOD!
I thank you all for trying to solve my problem, I shall return to this forum as soon I have bought another piece of their cisco junk!
-
@IrixOS why pfsense suck tho?
