Solved: Issue with RDP Connectivity to Peer Server from Ap...

aswin · ‎2023-05-23

Hello,

we are experiencing with the RDP connectivity to a peer server from our application subnet. As part of our infrastructure, we have hosted a checkpoint in the Azure Marketplace, specifically in Europe, Japan, and the US. The firewall management is handled through the Smart Console using Cluster XL HA Pair. We have successfully configured a site-to-site tunnel with a peer in the Europe firewall, and we have allowed the VPN domains subnets from both firewalls.

Upon conducting tests, we confirmed that the tunnel is up and running smoothly, and we are able to establish an RDP connection to the peer server from within the Europe subnet. However, when attempting to connect to the peer server's RDP from our US or Japan application subnet, we encounter an "Internal Error" message. It is worth noting that traceroute, telnet, and ping tests are all successful, and we can observe the corresponding encrypted tunnel logs in the firewall.

To investigate this issue further, I have compared the logs between the working and non-working scenarios, and they appear to be identical. Therefore, I am uncertain as to what might be causing this problem.

aswin · ‎2023-05-25

Hello Andy,

The issue is resolved. Actually Gateways are deployed in Azure and the Azure UDR is the problem for this connectivity issue. In UDR the traffic is routed from US ---> US Gateway ---> Europe Gateway, then the RDP is failed with Internal error.

We modified the US UDR for the subnets and send it directly to Europe Gateway instead of US, Then it start working now!!

Thanks,

Aswin

View solution in original post

PhoneBoy · ‎2023-05-23

Version/JHF of the relevant gateways/management?

Have you done any tcpdumps to see what might be happening at the application level (meaning at the RDP server)?
Have you done any debugging possibly with fw ctl zdebug + drop | grep ip-of-rdp-server

aswin · ‎2023-05-24

Hello PhoneBoy,

Thanks for your response. Both Management & Gateways current running version is R81.10.

I'm not get any debug deny log in for the destination IP in port 3389. Please find the below output from "fw monitor | grep "10.xx.x.x" ---> Peer End RDP server.

Working Output:

[vs_0][ppak_0] eth1:i[44]: 10.79.xx.xx -> 10.xx.xx.xx (TCP) len=59 id=21044
[vs_0][fw_0] eth1:I[44]: 10.79.xx.xx -> 10.xx.xx.xx (TCP) len=59 id=21044
[vs_0][fw_0] eth0:o[44]: 10.79.xx.xx -> 10.xx.xx.xx (TCP) len=59 id=21044
[vs_0][ppak_0] eth0:Oe[44]: 10.79.xx.xx -> 10.xx.xx.xx (TCP) len=59 id=21044

[vs_0][ppak_0] eth0:iD[44]: 10.xx.xx.xx -> 10.79.xx. (TCP) len=59 id=40074
[vs_0][ppak_0] eth0:i[44]: 10.xx.xx.xx -> 10.79.xx.xx (TCP) len=59 id=40074
[vs_0][fw_0] eth0:I[44]: 10.xx.xx.xx -> 10.79.xx.xx (TCP) len=59 id=40074
[vs_0][fw_0] eth1:o[44]: 10.xx.xx.xx -> 10.79.xx.xx (TCP) len=59 id=40074
[vs_0][fw_0] eth1:O[44]: 10.xx.xx.xx -> 10.79.xx.xx (TCP) len=59 id=40074

Non-Working Output:

[vs_0][ppak_0] eth1:i[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965
[vs_0][fw_0] eth1:i[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965
[vs_0][ppak_0] eth1:i[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965
[vs_0][fw_0] eth1:I[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965
[vs_0][fw_0] eth0:o[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965
[vs_0][ppak_0] eth0:Oe[44]: 10.15.xx.xx -> 10.xx.xx.xx (TCP) len=52 id=15965

[vs_0][ppak_0] eth0:iD[44]: 10.xx.xx.xx -> 10.15.xx.xx (TCP) len=52 id=30743
[vs_0][ppak_0] eth0:i[44]: 10.xx.xx.xx -> 10.15.xx.xx (TCP) len=52 id=30743
[vs_0][fw_0] eth0:I[44]: 10.xx.xx.xx -> 10.15.xx.xx (TCP) len=52 id=30743
[vs_0][fw_0] eth0:o[44]: 10.xx.xx.xx -> 10.15.xx.xx (TCP) len=52 id=30743
[vs_0][fw_0] eth0:O[44]: 10.xx.xx.xx -> 10.15.xx.xx (TCP) len=52 id=30743

VPN Community is configured in Europe firewall and in the network Management the Eth0 is External and Internal topology leads to only - 10.79.xx.xx subnet. And we facing internal error only with US & Japan, Europe is working fine.(Does this the cause the problem to send traffic to other gateways?)

Europe Gateway Subnet - 10.79.xx.xx

US Gateway Subnet - 10.15.xx.xx

Japan Gateway Subnet - 10.207.xx.xx

the_rock · ‎2023-05-24

Just to be 100% sure, if you can confirm, is traffic supposed to enter eth1 and leave on eth0?

Andy

aswin · ‎2023-05-24

Hello @the_rock

Yes, The traffic is coming into gateway via ETH1 and going out via ETH0

the_rock · ‎2023-05-24

Thats really odd then, because comparing working and non-working one, traffic flow appears to be exactly the same, unless my eyes are playing trick on me lol

Anyway, maybe try following:

fw ctl zdebug + drop | grep x.x.x.x (just replace x.x.x.x with affected IP address)

Andy

aswin · ‎2023-05-24

Hello Andy,

There is no drop log captured when I execute the " fw ctl zdebug + drop | grep x.x.x.x" with my affected IP.

Thanks

the_rock · ‎2023-05-24

K, fair enough. Can you do below, just to confirm (replace values first with working and then non working IP)

ip r g x.x.x.x

ip r g y.y.y.y

aswin · ‎2023-05-24

Hello Andy,

Please find the Output below

[Expert@gpeufwip] r g 10.79.248.xx
10.79.248.xx via 10.79.248.xx dev eth1 src 10.79.248.xx
cache
[Expert@gpeufw]# ip r g 10.15.248.xx
10.15.248.xx via 10.79.248.x dev eth0 src 10.79.248.x
cache
[Expert@gpeufw]# ip r g 10.207.248.xx
10.207.248.xx via 10.79.248.x dev eth0 src 10.79.248.x
cache

the_rock · ‎2023-05-24

Its okay, I like Randy too ; - ). I got lots of nicknames...Borat, Larry, Randy hahaha

Anywho, I see 2 of them show via eth0 and 1 via eth1, is that right?

Andy

aswin · ‎2023-05-24

Hello Borat, Larry, Randy, Andy 😉

Yes, your are right. 2 of them are via eth0 and 1 via eth1.

Eth1 is the firewall which actually the VPN community is configured with Gateway IP - 10.79.xx.xx.

One doubt: Is it require to configure separate tunnel in other Gateways (US & Japan) to get successful connection with peer server ? Because, currently VPN is configured in Europe Gateway and it's working fine for Europe subnets. In other gateways we not even announced the IPSec VPN in Gateway cluster properties.

Thanks for your understanding.

Aswin.

the_rock · ‎2023-05-24

You can also call me Mr Portokalo, thats cause I love movie "My big fat Greek wedding" and I do greek accent well lol ; - )

Anyway...do you have simple topology, it would help me understand this a bit better?

As far as your question for separate tunnel, here is my logic about it...as long as VPN is successful and tunnel shows up, then its fine, no need to play around with it.

By the way, say peer IP is 1.2.3.4, you can verify this by running command -> vpn tu tlist -p 1.2.3.4

Andy

aswin · ‎2023-05-24

Hi Mr.Portokalo 😊

Please find the below output for vpn tu tlist

(15) Site-to-Site tunnels are up:
IPSEC 15
NAT-T 0

(0) Number of Active Clients:
NAT-T 0
Visitor Mode 0
SSL 0
L2TP 0
StrongSwan 0

the_rock · ‎2023-05-24

So here is an idea. I recall once when I was on the phone with TAC, they asked us to do the following...vpn accel off peer_ip

example -> vpn accel off 1.2.3.4

Not saying it would fix your issue, but worth a try. If that does not work, then I would say may need more captures to try and figure out whats going on.

Cheers,

Andy

aswin · ‎2023-05-24

Thanks Andy,

will try and let you update here 😊

Cheers,

Aswin

the_rock · ‎2023-05-24

K, sounds good, keep us posted.

Andy

aswin · ‎2023-05-25

Hello Andy,

The issue is resolved. Actually Gateways are deployed in Azure and the Azure UDR is the problem for this connectivity issue. In UDR the traffic is routed from US ---> US Gateway ---> Europe Gateway, then the RDP is failed with Internal error.

We modified the US UDR for the subnets and send it directly to Europe Gateway instead of US, Then it start working now!!

Thanks,

Aswin

the_rock · ‎2023-05-25

Awesome job @aswin

Best regards,

Mr Portokalo 😉

Are you a member of CheckMates?

Issue with RDP Connectivity to Peer Server from Application Subnet