Drkrieger
New Contributor

Port forward not working?

Hello folks!

 

First off, I'm sure I've done something wrong, fully willing to admit it. I very recently upgraded to a Fortigate 60C from a 60B (Boss gave it to me for training purposes) and I had no issues with port forwarding on the older unit. Worked like a charm.

Now I'm running the 60C, I can't seem to get the port forward to work. 

 

First off, I'm running the following:

Device: Fortigate 60C (Rev. 1)

Firmware: v5.2.2,build642 (GA)

Internal Switch Mode: Interface (just to match our work environment for learning/testing purposes)

Security Features: All of them have been turned off for this testing (No AV, Intrusion Protection, etc)

 

I'm trying to do a port forward for a game server on my internal network. I've configured the server as a reserved DHCP so it will always have the same IP. I've created a Virtual IP for the port that needs to be forwarded (picture), then created a VIP Group and put the VIP into it. Then, I've created a IPv4 policy to forward traffic from my WAN port to the VIP Group, allowing all services, enabling the NAT and logging traffic (picture). To clarify, the 'Outside_Telus' address group looks like this: (picture)

 

As far as I know, that's all that is needed to get a port forward to work. When I do a specific NMap scan of the port, it says 'open|filtered', but the game server is not available in the games browser. I've tried to force the game to connect to the server directly, but so far no luck. 

 

Please let me know if anyone needs more information to help me solve this. I'll update if I figure it out.

 

Thanks in advance!

4 Solutions
emnoc
Esteemed Contributor III

Suggestions:

 

1:Disable "nat" for starters that should not be required on a DNAT ( VIP port-forward or 1-2-1 )

 

2: run diag debug flow to validate the  packets are matching the fwpolicy-id in question

 

3: run a diag sniffer packet against the  interfaces  or  any matching on the port

 

e.g ( if the port_forward was port 9999  and udp )

 

diag sniffer packet any "tcp and dst port 9999" 4

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

emnoc
Esteemed Contributor III

Your output is for  UDP is this vip-forward doing udp and tcp? Also do you have the correct fwpolicies and port(s)

 

back to your debug you typically want to set filters.

 

 

diag debug reset

 

diag debug en

diag debug flow filter  dport 9999

 diag debug flow filter saddr ( your client machine address ...optional )

diag debug flow  show console enable

diag debug flow trace start 100

 

 

Then run your nmap ( change the port in the above to match what  your running ). The more filters you apply on the flow diagnostic allows for you to monitor JUST for that trafffic that matches.

 

 

Remember to clear filters  by

 

1: A diag debug reset cmd

 

or

 

2   diag debug flow filter clear cmd

 

And re-engage if required

 

;)

 

 

PCNSE 

NSE 

StrongSwan  

View solution in original post

ashukla_FTNT

 

Ok, disabled the NAT (yep, just thought about that one... only need NAT for Inside->Outside).

Also ran the 'diag debuf flow' command in the CLI (did I need to add anything to that?)

Next, I ran the 'diag sniffer packet any "udp and dst port 12067" 4' and it came up with this when I ran NMap:

[attachImg]https://forum.fortinet.com/download.axd?file=0;121455&where=message&f=Snif_Results.JPG[/attachImg]

 

I've never ran a diag or sniffer before from the CLI, so I have no idea how to interpret the results.

What does this mean? I also had some random IP that my server was talking out to which resulted in a 'udp 25' at the end.

 

From the sniffer output it is very clear that firewall is doing dnat and sending it the the pc inside.

I highly suspect personal firewalll in pc blocking it.

Run wireshark on internal pc and check.

View solution in original post

ashukla_FTNT

Drkrieger wrote:

I've disabled WAN optimization, still no go :(

The WAN is Dynamic (this is being used on a residential ISP). I've tried using the 'any' for source address, but still didn't work. 

Let's see the wireshark capture.

If you don't see any incoming packet on wireshark then run the diag debug flow:

Connect using putty and enable logging to a file.

diag debug reset

diag debug disable

diag debug enable

diag debug flow filter addr <client ip>

diag debug flow show console enable

diag debug console timestamp enable

diag debug flow trace start 200

 

start nmap and once you test is done:

diag debug disable.

 

 

View solution in original post

14 REPLIES 14
emnoc
Esteemed Contributor III

Suggestions:

 

1:Disable "nat" for starters that should not be required on a DNAT ( VIP port-forward or 1-2-1 )

 

2: run diag debug flow to validate the  packets are matching the fwpolicy-id in question

 

3: run a diag sniffer packet against the  interfaces  or  any matching on the port

 

e.g ( if the port_forward was port 9999  and udp )

 

diag sniffer packet any "tcp and dst port 9999" 4

 

 

PCNSE 

NSE 

StrongSwan  

Drkrieger

emnoc wrote:

Suggestions:

 

1:Disable "nat" for starters that should not be required on a DNAT ( VIP port-forward or 1-2-1 )

 

2: run diag debug flow to validate the  packets are matching the fwpolicy-id in question

 

3: run a diag sniffer packet against the  interfaces  or  any matching on the port

 

e.g ( if the port_forward was port 9999  and udp )

 

diag sniffer packet any "tcp and dst port 9999" 4

 

Ok, disabled the NAT (yep, just thought about that one... only need NAT for Inside->Outside).

Also ran the 'diag debuf flow' command in the CLI (did I need to add anything to that?)

Next, I ran the 'diag sniffer packet any "udp and dst port 12067" 4' and it came up with this when I ran NMap:

 

I've never ran a diag or sniffer before from the CLI, so I have no idea how to interpret the results.

What does this mean? I also had some random IP that my server was talking out to which resulted in a 'udp 25' at the end.

 

 

ashukla_FTNT

 

Ok, disabled the NAT (yep, just thought about that one... only need NAT for Inside->Outside).

Also ran the 'diag debuf flow' command in the CLI (did I need to add anything to that?)

Next, I ran the 'diag sniffer packet any "udp and dst port 12067" 4' and it came up with this when I ran NMap:

[attachImg]https://forum.fortinet.com/download.axd?file=0;121455&where=message&f=Snif_Results.JPG[/attachImg]

 

I've never ran a diag or sniffer before from the CLI, so I have no idea how to interpret the results.

What does this mean? I also had some random IP that my server was talking out to which resulted in a 'udp 25' at the end.

 

From the sniffer output it is very clear that firewall is doing dnat and sending it the the pc inside.

I highly suspect personal firewalll in pc blocking it.

Run wireshark on internal pc and check.

Drkrieger

ashukla wrote:

 

From the sniffer output it is very clear that firewall is doing dnat and sending it the the pc inside.

I highly suspect personal firewalll in pc blocking it.

Run wireshark on internal pc and check.

I've disabled the Windows Firewall on the PC long before I had this issue. Thanks for the suggestion though :)

ashukla_FTNT

Drkrieger wrote:

 

I've disabled the Windows Firewall on the PC long before I had this issue. Thanks for the suggestion though :)

Can you run wireshark on the game server and check.

Also some antivirus program comes with firewall feature so please check.

Does this game server works from the same subnet (a pc with game browser in the same network)

if it is a windows server netstat-an shows the server listening on udp port port 12067 on the interface ip?

Do you have multiple network card on the server?

Drkrieger

Installing Wireshark as I write this, but never run it before. Fingers crossed!

 

There are no firewalls of any kind running on this. I'm only running MSSE for AV as the server is fairly insignificant. 

The game server works great when I point a game client from another local machine on the same subnet, no issues at all. 

There are two network cards, but the second card is disabled. Nothing on the server has changed at all, was working great on my Fortigate-60B (FortiOS 4.3) with no issues on the UDP port forwarding. 

 

Dave_Hall
Honored Contributor

Just curious on the VIP(s), are the source ports set as 1-65535 on the port forward part?

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

Drkrieger
New Contributor

Ok, so I've verified that if I open a port using this method for TCP, no issues at all. Opened up a port for a FTP server on port TCP 9400, no issues at all. NMap reports it as open as does a few other port checker sites. 

But the EXACT same settings, just selecting 'UDP' in the port forward option, will not forward at all. Port shows as 'open|filtered' on NMap, other sites show it as 'closed'. 

 

Any clues? I'm completely stumped now. 

emnoc
Esteemed Contributor III

Your output is for  UDP is this vip-forward doing udp and tcp? Also do you have the correct fwpolicies and port(s)

 

back to your debug you typically want to set filters.

 

 

diag debug reset

 

diag debug en

diag debug flow filter  dport 9999

 diag debug flow filter saddr ( your client machine address ...optional )

diag debug flow  show console enable

diag debug flow trace start 100

 

 

Then run your nmap ( change the port in the above to match what  your running ). The more filters you apply on the flow diagnostic allows for you to monitor JUST for that trafffic that matches.

 

 

Remember to clear filters  by

 

1: A diag debug reset cmd

 

or

 

2   diag debug flow filter clear cmd

 

And re-engage if required

 

;)

 

 

PCNSE 

NSE 

StrongSwan