I am struggling to find the source of a failure to port forward. Most likely a dumb user error, but I just can't see where the issue is.
I have set up 3 virtual IPs from a WAN interface to a local interface forwarding three different ports, tied them to a VIP group and then put in a policy to enable the routing. So far so good.
On one of the ports, I can telnet from WAN and get a response from the destination server, but on the other ports, I get nothing back. From the LAN, I can hit all three ports just fine; so it does not appear to be a problem with the destination server.
When I try to telnet to port 6281 from the WAN I get the following sniffer output (three retries with no response)
FG100D3G14800997 # diag snif packet lan 'port 6281' 4
interfaces=[lan]
filters=[port 6281]
5.186717 lan -- 192.168.25.130.59321 -> 96.xx.xx.xx.6281: syn 1061727477
8.188726 lan -- 192.168.25.130.59321 -> 96.xx.xx.xx.6281: syn 1061727477
14.192043 lan -- 192.168.25.130.59321 -> 96.xx.xx.xx.6281: syn 1061727477
But doing the telnet to port 22, you can see that it is routing is working.
FG100D3G14800997 # diag snif packet lan 'port 22' 4
interfaces=[lan]
filters=[port 22]
3.549354 lan -- 192.168.25.130.59296 -> 96.xx.xx.xx.22: syn 583024486
3.549446 lan -- 192.168.25.2.59296 -> 192.168.25.21.22: syn 583024486
3.549642 lan -- 192.168.25.21.22 -> 192.168.25.2.59296: syn 4254475213 ack 583024487
3.549705 lan -- 96.xx.xx.xx.22 -> 192.168.25.130.59296: syn 4254475213 ack 583024487
3.550396 lan -- 192.168.25.130.59296 -> 96.xx.xx.xx.22: ack 4254475214
The VIP and the policies are all in the same rule....what am I missing here?
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.
I finally figured out where the issue is coming from but not sure why...
The issue turned out to be when I created the services for the other two ports. I set the source and destination ports the same; so in service 1, I created it with port 6281 as the source and destination and did the same with service 2 port 6690.
The problem is that when the source port is specified, traffic is blocked.
My question then is, if I have a VIP coming into a specific port and being routed to a server using the same port, why does the source have to be blank? Why does it not work to have the source and destination both specified?
What do you mean by "source" and "destination" in the context "service" creation? Can you share the actual config after masking some sensitive parts?
First your FortiOS seems to be quite old. With 5.4.8 I have "Specify Source Ports" option in "Service" config is disabled by default. By default, if you don't specify the port range, either "destination" or "source" use the default range "0-65535", which would include your first example:
192.168.25.130.59321 -> 96.xx.xx.xx.6281 : source=59321, destination=6281 Don't get confused with "External Port" and "Mapped Port" in "VIP" config, which could be 6281->6281 in case you don't have to change at the FGT. You, in most cases, you should leave the "source port range" as blank because you don't know what port the client devices would pick.The sniffer is what clued me in to removing the source port, but my understanding about what 'source' meant was wrong. I thought source was relative to the interface not to the client's 'source'. Makes sense now. Thanks for the feedback....I knew is was a dumb user error.
Service ports are ALWAYS destination ports - that's how it is defined in TCP/IP. This is not vendor specific.
The client is free to choose any source port from 1024-65535 (except for some odd services where the source and destination ports are the same - for whatever reason).
Just imagine the client is using NAT - each session will have the same source address but a different (NAT) source port, temporarily.
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 |
---|---|
1632 | |
1063 | |
749 | |
443 | |
210 |
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.