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!
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
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 wrote:Let's see the wireshark capture.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.
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.
emnoc wrote:Your output is for UDP is this vip-forward doing udp and tcp? Also do you have the correct fwpolicies and port(s)
Yep, it's UDP on the port in question. I opened up a port for an FTP server on the same computer under TCP, so I then created a VIP group and put both VIP's (12067 UDP, 9400 TCP) into the group. They both point to the same IP address.
As for the fwpolicies, I've selected 'ALL' under destination services which should allow all traffic to the destination addresses, should it not?
I'll try out the diags later when I'm not at home.
IF nothing changed in the network other than firewall then there is highly unlikely there is anything wrong in the server.
I just recommended checking the server because sniff shows packet sent inside.
Just noticed wan optimization is also enabled on policy, try disabling it and test asthis can cause issues sometimes.
Also for source address you can use any instead of outside_telus (though there should not be any issue with outise_telus, but just trying out)
Do you have dyanmic ip on wan as i see you are using 0.0.0.0 for external ip on vip?
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.
Drkrieger wrote:Let's see the wireshark capture.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.
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.
ashukla wrote:
Let's see the wireshark capture.
Alrighty, so Wireshark is confirming that there are some packets traveling, and for some reason, it's now all working.
I'm running into an issue with the duckdns, but when I go to the IP it's all working. No idea what changed.
But thank you all so much for the tips, I've actually learned quite a bit here :D
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1688 | |
1086 | |
752 | |
446 | |
226 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.