|
Assumptions: GUI is supposed to be accessible using https://10.109.16.74 where the IP 10.109.16.74 is IP of wan1 interface:
config system interface
edit "wan1"
set vdom "root"
set ip 10.109.16.74 255.255.240.0 <<---
set allowaccess ping https ssh http telnet
next
end
And also the default route 0.0.0.0/0 is via the wan1 interface:
FGT # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
V - BGP VPNv4
* - candidate default
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 10.109.31.254, wan1, [1/0] <-----
C 10.109.16.0/20 is directly connected, wan1
C 10.146.0.0/20 is directly connected, port1
C 192.168.1.0/24 is directly connected, lan
- Use the following flow debugging commands to capture the flow of the traffic:
FGT # diagnose debug flow filter clear
FGT # diagnose debug flow filter addr <source IP address>
FGT # diagnose debug flow filter proto 1<----- Or run 'diagnose debug flow filter port <destination port>' for capturing the logs for standard ports 443, 80, or 22 as destination port
FGT # diagnose debug flow trace start 100
FGT # diagnose debug enable
Here is an example log for ping:
SSLVPN-server # id=65308 trace_id=25 func=print_pkt_detail line=5899 msg="vd-root:0 received a packet(proto=1, 10.109.16.186:4864->10.109.16.74:2048) tun_id=0.0.0.0 from wan1. type=8, code=0, id=4864, seq=0."
id=65308 trace_id=25 func=init_ip_session_common line=6073 msg="allocate a new session-000197ba, tun_id=0.0.0.0"
id=65308 trace_id=25 func=get_new_addr line=1232 msg="find DNAT: IP-10.108.4.69, port-0(fixed port)"
id=65308 trace_id=25 func=fw_pre_route_handler line=181 msg="VIP-10.108.4.69:4864, outdev-wan1"
id=65308 trace_id=25 func=__ip_session_run_tuple line=3528 msg="DNAT 10.109.16.74:8->10.108.4.69:4864" <-----
id=65308 trace_id=25 func=vf_ip_route_input_common line=2606 msg="find a route: flag=05000000 gw-10.109.31.254 via wan1"
id=65308 trace_id=25 func=fw_forward_handler line=753 msg="Denied by forward policy check (policy 0)" <-----
As per the above logs, the traffic is matching VIP, and traffic is blocked due to the error message 'Denied by forward policy check (policy 0)'.
The error message 'Denied by forward policy check (policy 0)' is seen when there is no firewall policy to allow the traffic but the GUI access from the internet does not need a firewall policy, also, the GUI access from the internet should not hit the VIP.
If there is a configured VIP on the FortiGate using IP address of the GUI (10.109.16.74 in the above example) and standard destination port number 443, 80 or 22 and the VIP has been enabled on firewall policy, the traffic is destinated to the IP address of the GUI with standard destination port (443, 80 and 22) will hit the VIP:
config firewall vip
edit "webserver-vip"
set extip 10.109.16.74
set mappedip "10.108.4.69"
set extintf "wan1"
next
end
config firewall policy
edit 4
set name "VIP"
set srcintf "wan1"
set dstintf "port1"
set action accept
set srcaddr "all"
set dstaddr "webserver-vip" <-----
set schedule "always"
set service "ALL"
set inspection-mode proxy
next
end
Solutions:
Enable port forwarding in VIP with a specific port number that the VIP is created for. For example, the below VIP will not affect the GUI access via DST ports 443 or 80, or 22:
config firewall vip
edit "webserver-vip"
set extip 10.109.16.74
set mappedip "10.108.4.69"
set extintf "wan1"
set portforward enable <-----
set extport 3389
set mappedport 3389
next
end
Use a different non-standard port number for GUI/SSH access under system settings in case the VIP is used to access the internal servers via standard ports 443, 80, or 22:
config system global
set admin-sport 11443 <-----
set admin-ssh-port 5522 <-----
end
|
