Austrian_Des
asked on
How to configure FortiGate 90D (4.2.3) to route RDP over 1 WAN and all other traffic over a 2nd WAN
Hi All,
As you can see from the title, I'm trying to configure a Fortigate 90D (Firmware: v5.2.3,build670) to utilise dual WAN circuits.
Actions taken so far:
1. Both WAN circuits connected, configured and showing as “Up”
2. Static Routes configured for both WANs
3. IPv4 Policy Routes configured for “RDP” (3389) on Wan_1 and “Everything Else” on Wan_2
Observed results:
1. All protocols work correctly except RDP
2. By changing the Distance / Priority of the Static Routes it is possible to make RDP work but nothing else.
Notes:
• Wan_1 was the 1st configured WAN and originally all policies used that as the “Outgoing Interface”.
• When Wan_2 was installed the policies were edited to use Wan_2 as the “Outgoing Interface”.
• Reviewing the Forward traffic log shows that the RDP packets (destined for Wan_1) are being “denied” with a “Destination Interface” of Wan_2 i.e. the wrong interface
• It “feels” as though only policies for Wan_1 OR Wan_2 are being processed depending on the Static route values
I'm happy to provide all and any further info required.
All thoughts welcome
Cheers,
Des
As you can see from the title, I'm trying to configure a Fortigate 90D (Firmware: v5.2.3,build670) to utilise dual WAN circuits.
Actions taken so far:
1. Both WAN circuits connected, configured and showing as “Up”
2. Static Routes configured for both WANs
3. IPv4 Policy Routes configured for “RDP” (3389) on Wan_1 and “Everything Else” on Wan_2
Observed results:
1. All protocols work correctly except RDP
2. By changing the Distance / Priority of the Static Routes it is possible to make RDP work but nothing else.
Notes:
• Wan_1 was the 1st configured WAN and originally all policies used that as the “Outgoing Interface”.
• When Wan_2 was installed the policies were edited to use Wan_2 as the “Outgoing Interface”.
• Reviewing the Forward traffic log shows that the RDP packets (destined for Wan_1) are being “denied” with a “Destination Interface” of Wan_2 i.e. the wrong interface
• It “feels” as though only policies for Wan_1 OR Wan_2 are being processed depending on the Static route values
I'm happy to provide all and any further info required.
All thoughts welcome
Cheers,
Des
Can you post the following parts of the config/screenshot:
-Routing table/static routes
-Policy routing statements
Tamas
-Routing table/static routes
-Policy routing statements
Tamas
Also, shouldn't make a difference, but 5.2.4 has been out quite a while and running pretty well, so you may want to also consider updating that some time, too
ASKER
Hi Guys,
Sorry for the slow reply.
So taking the questions in turn:
1. When I run the diag snif, I see the packets sending the SYN but nothing else. There is no interface information displayed (do I need to use a different level of reporting to see interface info?)
2. Here are the two configs:
config router static
edit 2
set gateway xx.yy.207.173
set distance 20
set device "wan1"
next
edit 3
set gateway 192.168.61.8
set device "wan2"
next
end
config firewall policy
edit 2
set uuid 7180bfc8-90ea-51e5-3484-37 0c8c6c1b8c
set srcintf "internal"
set dstintf "wan2"
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "RDP"
set logtraffic all
next
edit 1
set uuid 2fe9b60a-90ea-51e5-f43a-66 ed45167523
set srcintf "internal"
set dstintf "wan2"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
edit 3
set uuid f79b640e-90eb-51e5-064e-96 3a36b4b5ae
set srcintf "internal"
set dstintf "wan1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "RDP"
set nat enable
next
end
3. I was due to update the firmware but didn’t want to confuse this routing issue with changes made by a firmware update – 1 change at a time sounds good to me ;-)
Possibly not relevant but here is the output of get router info routing-table all:
S* 0.0.0.0/0 [10/0] via 192.168.61.8, wan2
C xx.yy.207.172/30 is directly connected, wan1
C 192.168.60.0/24 is directly connected, internal
C 192.168.61.0/24 is directly connected, wan2
If I set both routes to the same distance of 10 then I get:
S* 0.0.0.0/0 [10/0] via xx.yy.207.173, wan1
[10/0] via 192.168.61.8, wan2
C xx.yy.207.172/30 is directly connected, wan1
C 192.168.60.0/24 is directly connected, internal
C 192.168.61.0/24 is directly connected, wan2
But having done so neither RDP or any other service can access the outside world.
If I set wan1 to a distance of 10 and wan2 to 20 then RDP works but nothing else.
Finally, if I look at the “WAN Link Load Balancing” page then I see that “Source IP Based” is selected but there are no matching entries found in the “Interface Members” grid – Is this relevant?
Thanks again,
Des
Sorry for the slow reply.
So taking the questions in turn:
1. When I run the diag snif, I see the packets sending the SYN but nothing else. There is no interface information displayed (do I need to use a different level of reporting to see interface info?)
2. Here are the two configs:
config router static
edit 2
set gateway xx.yy.207.173
set distance 20
set device "wan1"
next
edit 3
set gateway 192.168.61.8
set device "wan2"
next
end
config firewall policy
edit 2
set uuid 7180bfc8-90ea-51e5-3484-37
set srcintf "internal"
set dstintf "wan2"
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "RDP"
set logtraffic all
next
edit 1
set uuid 2fe9b60a-90ea-51e5-f43a-66
set srcintf "internal"
set dstintf "wan2"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
edit 3
set uuid f79b640e-90eb-51e5-064e-96
set srcintf "internal"
set dstintf "wan1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "RDP"
set nat enable
next
end
3. I was due to update the firmware but didn’t want to confuse this routing issue with changes made by a firmware update – 1 change at a time sounds good to me ;-)
Possibly not relevant but here is the output of get router info routing-table all:
S* 0.0.0.0/0 [10/0] via 192.168.61.8, wan2
C xx.yy.207.172/30 is directly connected, wan1
C 192.168.60.0/24 is directly connected, internal
C 192.168.61.0/24 is directly connected, wan2
If I set both routes to the same distance of 10 then I get:
S* 0.0.0.0/0 [10/0] via xx.yy.207.173, wan1
[10/0] via 192.168.61.8, wan2
C xx.yy.207.172/30 is directly connected, wan1
C 192.168.60.0/24 is directly connected, internal
C 192.168.61.0/24 is directly connected, wan2
But having done so neither RDP or any other service can access the outside world.
If I set wan1 to a distance of 10 and wan2 to 20 then RDP works but nothing else.
Finally, if I look at the “WAN Link Load Balancing” page then I see that “Source IP Based” is selected but there are no matching entries found in the “Interface Members” grid – Is this relevant?
Thanks again,
Des
When I run the diag snif, I see the packets sending the SYN but nothing else. There is no interface information displayed (do I need to use a different level of reporting to see interface info?)Did you add the "4" after the filter argument? Without it, you will only see a packet once in igress ... re-check and post the result (sanitized if required, but keep the addresses in a way that allow for identification)
ASKER
Hi Garry,
Yes I did add the 4 and here is the output:
FGT_90D_zzz# diag snif pack any "tcp port 3389" 4
interfaces=[any]
filters=[tcp port 3389]
5.100242 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
8.101697 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
14.103448 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
Hope this helps!
Yes I did add the 4 and here is the output:
FGT_90D_zzz# diag snif pack any "tcp port 3389" 4
interfaces=[any]
filters=[tcp port 3389]
5.100242 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
8.101697 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
14.103448 internal in 192.168.60.20.52305 -> 46.163.106.xx.3389: syn 3963976044
Hope this helps!
OK, the packet is not sent out, so either you have a problem with your policies not allowing the forwarding, or the FG thinks something else is wrong ... not sure if this is the reason in this case, but did you enable asymmetric forwarding (conf system settings ; set asyrmoute enable)? If it is not enabled, try if this fixes it ... otherwise we'd have to do a flow trace ti see which rules are used and where the forwarding process is denied ...
ASKER
Hi Garry,
Ok we I enabled the asymetric forwarding, but no change.
Looking at the flow trace I see:
FGT_90D_zzz # id=20085 trace_id=10101 func=print_pkt_detail line=4378 msg="vd-root received a packet(proto=6, 192.168.60.20:52522->46.16 3.106.xx:3 389) from internal. flag [S], seq 2799451685, ack 0, win 8192"
id=20085 trace_id=10101 func=init_ip_session_commo n line=4527 msg="allocate a new session-0002a92f"
id=20085 trace_id=10101 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-192.168.61.8 via wan2"
id=20085 trace_id=10101 func=fw_forward_handler line=545 msg="Denied by forward policy check (policy 0)"
So clearly it is seeing the 1st (lowest distance) route, which is wan2, as the option to go for and then it naturally hits the denied policy ...
Any ideas on how to proceed would be great!
Cheers,
Des
Ok we I enabled the asymetric forwarding, but no change.
Looking at the flow trace I see:
FGT_90D_zzz # id=20085 trace_id=10101 func=print_pkt_detail line=4378 msg="vd-root received a packet(proto=6, 192.168.60.20:52522->46.16
id=20085 trace_id=10101 func=init_ip_session_commo
id=20085 trace_id=10101 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-192.168.61.8 via wan2"
id=20085 trace_id=10101 func=fw_forward_handler line=545 msg="Denied by forward policy check (policy 0)"
So clearly it is seeing the 1st (lowest distance) route, which is wan2, as the option to go for and then it naturally hits the denied policy ...
Any ideas on how to proceed would be great!
Cheers,
Des
Did you leave NAT out on Policy 2 on purpose?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Talking about the firewall policy, not the policy route
ASKER
Garry,: Policy 2 is the RDP DENY on wan2 - Is that what you're talking about?
Qlemo: Thanks for your input but that whole screen doesn't look like anything I see on 5.2.3.
Des
Qlemo: Thanks for your input but that whole screen doesn't look like anything I see on 5.2.3.
Des
Might be it is FortiOS 4 related - the screenshot is from a 80C with 4.0 - but http://blog.webernetz.net/2015/07/20/policy-routing-on-a-fortigate-firewall/ shows the same location on a 90D and is of this year, so should be 5.x ...
Sorry, missed the missing allow on fw policy 2 ...
Could you post the policy route part of the config?
Could you post the policy route part of the config?
ASKER
Garry / Qlemo - I am confused ... Before I started on this whole episode I had expected to "simply" create a policy / policy route to enable me to send pakets via different WANs based on a set of rules. Reading the "FortiOS™ Handbook Advanced Routing for FortiOS 5.0" on page 25 it says:
Policy routing enables you to redirect traffic away from a static route. This can be useful if you want to route certain types of network traffic differently. You can use incoming traffic’s protocol, source address or interface, destination address, or port number to determine where to send the traffic. For example, generally network traffic would go to the router of a subnet, but you might want to direct SMTP or POP3 traffic directly to the mail server on that subnet.
It then describes how to do this:
Policy route options define which attributes of a incoming packet cause policy routing to occur. If the attributes of a packet match all the specified conditions, the FortiGate unit routes the packet through the specified interface to the specified gateway.
To view policy routes go to Router > Static > Policy Routes.
So this is (was) exactly what I expected to be doing, however when I look at my GUI I don't have a Router > Static > Policy Routes.
So is the real problem here that I am trying to do this via a GUI that doesn't support "Policy Routes"?
By the way I have upgraded now to v5.2.4 build 688.
Thanks,
Des
Policy routing enables you to redirect traffic away from a static route. This can be useful if you want to route certain types of network traffic differently. You can use incoming traffic’s protocol, source address or interface, destination address, or port number to determine where to send the traffic. For example, generally network traffic would go to the router of a subnet, but you might want to direct SMTP or POP3 traffic directly to the mail server on that subnet.
It then describes how to do this:
Policy route options define which attributes of a incoming packet cause policy routing to occur. If the attributes of a packet match all the specified conditions, the FortiGate unit routes the packet through the specified interface to the specified gateway.
To view policy routes go to Router > Static > Policy Routes.
So this is (was) exactly what I expected to be doing, however when I look at my GUI I don't have a Router > Static > Policy Routes.
So is the real problem here that I am trying to do this via a GUI that doesn't support "Policy Routes"?
By the way I have upgraded now to v5.2.4 build 688.
Thanks,
Des
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Garry,- I had been to that widget and had enabled "Advanced Routing" in the past BUT had never noticed that it took a while for the GUI to display the "Apply" button. I have just tried that and now I have the fabled "Router" main menu item :-) I will setup the routes and test and let you know how things go - It could be that this was the magic moment I needed!
Thanks,
Des
Thanks,
Des
ASKER
Hi Garry,
I can confirm that once the "Router" option became visible on the menu bar I was able to configure a policy route and now everything is working as expected! The only thing which I had to do which was unexpected was to set the "distance" of the 2 wans to different values - Perhaps there's some more work to do when the distance values are the same?
However, for now the problem is solved - Thanks very much!
I can confirm that once the "Router" option became visible on the menu bar I was able to configure a policy route and now everything is working as expected! The only thing which I had to do which was unexpected was to set the "distance" of the 2 wans to different values - Perhaps there's some more work to do when the distance values are the same?
However, for now the problem is solved - Thanks very much!
I don't agree to the way the question got closed. I was absolutely correct with http:#a41293967, you just needed the added info how to enable the GUI option to setup what I said, as given by Garry-G in http:#a41307468 (the accepted answer). Before that, you were on the wrong track.
ASKER
Qlemo - Thanks for your comment but I am unsure how to correct / proceed in this case. What is the standard proceedure for resolving this type of complaint against me? Do I need to do something or is there an "appeal proceedure" that you invoke?
I am unsure of the scale of the impact that my closure process has on you but in my post #41297184 I clearly identified the fact that I had no "Router" menu option. Garry then explained how to get that option in his post #41307468
Obviously the last thing I wish to do is upset anyone especailly as my problem was resolved but what to do now? ...
I am unsure of the scale of the impact that my closure process has on you but in my post #41297184 I clearly identified the fact that I had no "Router" menu option. Garry then explained how to get that option in his post #41307468
Obviously the last thing I wish to do is upset anyone especailly as my problem was resolved but what to do now? ...
My answer was correct, and the solution. That you could not see the menu option is different, and Garry helped with that. So I would expect a fifty-fifty share, accepting both comments.
ASKER
I have tried to be fair with my closure but to be honest the stress of closure was not very pleasent. I hope everyone is now happy.
diag snif pack any "tcp port 3389" 4
Are they actually forwarded out the correct interface?