Skip to main content
ragno
ragno
New Member
March 16, 2015
Question

Virtual IP for enable RDP

  • March 16, 2015
  • 9 replies
  • 53984 views

Hi,

 

I'm trying to make the settings on Fortigate to enable the RDP to a server but is not working.

I made the Virtual IP settings and I created the policy:

 

what is the problem?

 

VIRTUAL IP:

Name: RDP_virtualIP External Interface: wan1

External IP: 999.999.999.999 (I put the correct external ISP IP)

Mapped IP: 192.168.100.30

Port fowarding: enabled

External service port:3389/3389 Map to Port: 3389/3389

 

POLICY

From: wan1

To: vlan100

Source: all

Destination: RDP_virtualIP

Nat: disabled

 

In the logs I can see the pc outside that is trying to connect, it is not being blocked but doesn't works.

I placed the policy on the top of the rules but doesnt worked too.

9 replies

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 16, 2015

Can you run a sniff and flow trace to see what is happening to the traffic each step of the way?

 

1. diag sniffer packet any "host w.x.y.z and port 3389" 4 //--replace w.x.y.z with the public IP of the client (not the External IP or the Mapped IP; both these will change between wan1 and vlan100) connecting inbound to the server

-Press Ctl+C to stop the capture once you gather enough packets to see where the problem occurs

 

2. Run the flow trace if the sniff doesn't make the problem obvious to find:

diag debug reset

diag debug enable

diag debug flow show console enable

diag debug flow show function-name enable

diag debug flow filter addr w.x.y.z //--again, use the public IP of the incoming client

diag debug flow filter port 3389

diag debug flow trace start 5000

<attempt to connect, then...>

diag debug flow trace stop

diag debug flow filter clear

diag debug reset

diag debug disable

 

If you perform a find/replace on the External IP that appears in the output, as well as the client IP, then you can still mask their real values and post the output to this chat thread.

ragno
ragnoAuthor
New Member
March 16, 2015

The VLAN is 10 and not 100. But the ip is correct.

The 188.88.88.88 is my ISP ip connected to fortigate.

The 155.55.55.254 is the outside client IP.

 

 

 

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 16, 2015

Okay...the flow trace shows essentially what you said; the packets are not being blocked. The FortiGate recognizes subsequent packets to belong to the existing session.

 

Does the sniff show the packets leaving towards the server?

ragno
ragnoAuthor
New Member
March 16, 2015

Christopher McMullan_FTNT wrote:

Okay...the flow trace shows essentially what you said; the packets are not being blocked. The FortiGate recognizes subsequent packets to belong to the existing session.

 

Does the sniff show the packets leaving towards the server?

In that image is all the logs that shown to me, nothing more...

rwpatterson
rwpatterson
New Member
March 16, 2015

In the policy, what service did you use? All/Any, built-in RDP, or your own custom RDP?

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 16, 2015

Okay, try running the sniff again:

 

diag sniffer packet any "host w.x.y.z and port 3389" 4

ragno
ragnoAuthor
New Member
March 16, 2015

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 16, 2015

Alright...it looks as if the packet leaves 'on the wire' towards the RDP server. Can you check the server logs to see why it does not reply?

Iescudero
Iescudero
New Member
March 16, 2015

Hi to all!

maybe this is obvious, but just wondering. you get from the server to fortigate and vice versa with a ping?

 

Bye!

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 16, 2015

escudero wrote:

Hi to all!

maybe this is obvious, but just wondering. you get from the server to fortigate and vice versa with a ping?

 

Bye!

That raises a good question: what is the server's gateway? Is it the FortiGate?

 

Better to check the server logs anyway, since we know the traffic reaches the server. The FortiGate is not blocking it. See if it's related to the source IP of the request, or source OS version (newer or older verion of Remote Desktop?), or else the wrong gateway in the host routing table.

ragno
ragnoAuthor
New Member
March 16, 2015

Christopher McMullan_FTNT wrote:

escudero wrote:

Hi to all!

maybe this is obvious, but just wondering. you get from the server to fortigate and vice versa with a ping?

 

Bye!

That raises a good question: what is the server's gateway? Is it the FortiGate?

 

Better to check the server logs anyway, since we know the traffic reaches the server. The FortiGate is not blocking it. See if it's related to the source IP of the request, or source OS version (newer or older verion of Remote Desktop?), or else the wrong gateway in the host routing table.

The server pings the fortigate vlan 10 interface and vice-versa.

 

The gateway is the IP of the VLAN 10 interface on Fortigate since is it who is making the intervlan routing.

The route print shows the same gateway as the ethernet adapter properties.

 

Checked if Windows Firewall was turned on and is off already.

 

The windows logs in not showing any problem, is showing the lan RDP sessions only that a I did my self inside the LAN.

 

I installed wireshark on the server and tryed to monitor but no communications related to the RDP process is shown.

 

The server is completely updated.

 

I did another test on a PC instead the server and the same problem occurs.

ragno
ragnoAuthor
New Member
March 17, 2015

I changed the policy to this way:

 

From: wan1 To: vlan10

source: 155.55.55.254 (outside client public ip)

Destination: rdp_vip

Schedule: always Service: all

Action: Accept

NAT: I tryed the 3 ways = disabled, enabled, enabled+fixed port

 

Also I tryed to set in Virtual IP the External IP Address/Range as: 0.0.0.0/0.0.0.0

 

Using version v5.0,build0305 (GA Patch 10)

 

 

 

Robin_Svanberg
Robin_Svanberg
New Member
March 17, 2015

Ok, strange issue. I guess nothing worked? :)

 

If you enable NAT, can you collect the output of "diag sniff packet any 'host 192.168.100.30' 4" the same time you try to connect? Just want to see if there´s any ARP requests or similiar to 192.168.100.30.

Christopher_McMullan
Staff
Christopher_McMullan
Staff
March 17, 2015

It would also still be very useful to review any logs generated on the server itself once connection attempts are made.

Dave_Hall
Dave_Hall
New Member
March 17, 2015

@OP

 

Perhaps you can provide the CLI script equivalent, we may be able to spot something. eg.

 

config firewall service custom     edit "rdp-port-list"         set tcp-portrange 3389-3389:0-65535     next end config firewall vip     edit "RDP-Server1"         set extintf "wan1"         set portforward enable         set mappedip 192.168.100.30         set extport 3389         set mappedport 3389     next end config firewall policy     edit 0         set srcintf "wan1"         set dstintf "dmz_net"         set srcaddr "remote-admin-pc"         set dstaddr "RDP-Server1"         set action accept         set schedule "always"         set service "rdp-port-list"         [style="background-color: #ff0000;"]set nat enable[/style]     next end

 

ragno
ragnoAuthor
New Member
March 23, 2015

Solved the problem: I just changed the port to 3386 on windows registry

(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber) and now is working. 

 

But I didn't understand why 3389 doesn't works.

Terms & ConditionsAccessibility statement