Hi all,
I've already checked tons of manuals, forums, kbs and cookbooks, made hundreds of experiments on live hardware, but can't find the way to do very simple thing - negating defined split-tunneling subnets for remote WLANs. I mean subnets, which are defined in config wireless-controller wtp-profile / edit <profile> / conf split-tunneling-acl. It is nice feature but working opposite way it should - defined subnets are NOT routed to wireless controller.
In most cases, traveler with FAP expecting direct access to corp network without other external resources slowdowns, which is 100% occurs, if we route all SSID traffic to WLC. Just imagine, how slow it could be, if remote WLAN deployed in hotel in Hong Kong, but WLC is on duty at Portugal.
So I think it is quite normal to define just one (or few) subnets (internal corporate network) to route via WLC, and rest of traffic should go through local FAP GW. For now, to implement this, and make just one subnet (192.168.0.0/16) to be routed to WLC, I should define 15 subnets in wtp-profile, and it is almost maximum supported number (you can't define more than 16 subnets there). So it is not possible to add even one more routable subnet (lets say, 10.11.232.0/24).
Hope I'm missing something, that's why I decided to post it here - maybe someone already knows how to ...
Thanks!
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.
From release 5.4.6 and 5.6.3, an enhancement in this area has been added. You can set a default action to either Local or tunnel and use ACL to configure exception.
FW80CM3913601573 (S321C) # set split-tunneling-acl-path ? tunnel Split tunneling ACL list traffic will be tunnel. local Split tunneling ACL list traffic will be local NATed
Hi crasher,
For 5.6, it will be in 5.6.3 I have corrected original post.
Same cfg as yours, but absolutely no effect on set split-tunneling-acl-path local or tunnel - ACL works as before, subnets in ACL are excluded from tunnel routing, not included not matters which setting is in use.
So, lets say, I'm pinging 192.168.198.1 from FAP-side OK, but right after adding 192.168.198.1/32 in ACL, pings are stopped immediately (actually, started to be routed via default FAP gw, and it says "network unreachable" after some delay).
I've latest 5.6.1 FW on FAP21D, but very strange - I can't telnet/ssh to it even after set allowaccess telnet http ssh (just timeouts) when it operates in normal mode (associated with FG and got two IPs with one last digit difference in MACs from FG's dhcp), only in standalone mode to 192.168.1.2. But in this mode ifconfigs shows nothing interesting. :(
This new enhancement requires FAP code to be upgraded as well. The FAP GA is not released yet. current 5.6.1 doesn't have the FAP side change.
As for allow-access, please make sure you can ping the AP with the address that you can see under FGT GUI/Managed AP page.
Wow... I think that should be mentioned first, about FAP FW which is not released yet. :)))
So all that I trying to do should not work until new FW released? Current GA is 5.6.1 Build 0476 which I'm playing with, and it does not support this enhancement, right?
As for allow-access, I have simple config:
FAP21D(LAN) <==> (LAN)ROUTER(WAN) <==> [INTERNET] <==> (WAN)FGT
So it is normal that you can't ping and interact with FAP LAN IP (which is displayed in FGT GUI/Managed AP) from FGT. But from FAP-side LAN, yes, I can ping FAP LAN IP, but any connections to it are refused (telnet/ssh/http).
Also I see two FAP tunnel IPs on FGT's DHCP leases, and that IPs I can ping from FGT side, but it is also not possible to connect to FAP using that IPs (timeouts).
Hi Sergey,
Yes. In order for the new enhancement to work, FAP side has to support this.
For telnet/ssh/http access, I noticed that you didn't enable them from wtp-profile, Please try to add that in the wtp-profile using command "set allow-access telnet http ssh" and you should be good to go
Lei
Hi Lei,
wanglei@fortinet.com wrote:
Yes. In order for the new enhancement to work, FAP side has to support this.
Maybe you have any ETA for this update? :)
wanglei@fortinet.com wrote:
For telnet/ssh/http access, I noticed that you didn't enable them from wtp-profile, Please try to add that in the wtp-profile using command "set allow-access telnet http ssh" and you should be good to go
Yes, my previous config I've posted was missing allowaccess, but later I've added it and mentioned it in my previous msg: "I can't telnet/ssh to it even after set allowaccess telnet http ssh (just timeouts) when it operates in normal mode". But still no access to FAP from any side (FAP's LAN IP or tunnel IPs on FG-side). FAP LAN IP gives connection refused, tunnel IPs - timeouts, but at the same time, they are all pingable.
Hi Crasher,
I don't have that info on when the next release will be but it should be soon : )
As for allowaccess, we only allow remote access to AP via AP's management IP ( the one shows up in FGT managed AP page). It should be very straightforward configuration. Once you enable it, you can telnet into the box. Please bind a default profile to the AP and see whether it works.
Hi Lei!
I'm very happy today! :)
Upgraded my fap21d with latest 5.6.2 and ... split tunneling started to work as expected.. FINALLY! Need to have couple of beers to celebrate! :))
Just one small issue that I still can't telnet/ssh to my fap when it connected to fg. Allowacces is on place, but no luck from any side (fgt or local fap subnet).. Timeouts.
config wireless-controller wtp-profile
edit "fap21d-new"
config platform
set type 21D
end
config lan
set port-mode bridge-to-ssid
set port-ssid "MyFAP21"
end
set ap-country US
set split-tunneling-acl-path tunnel
set split-tunneling-acl-local-ap-subnet enable
config split-tunneling-acl
edit 1
set dest-ip 192.168.1.0 255.255.255.0
next
edit 2
set dest-ip 192.168.16.0 255.255.255.0
next
edit 3
set dest-ip 192.168.95.0 255.255.255.0
next
edit 4
set dest-ip 192.168.118.0 255.255.255.0
next
edit 5
set dest-ip 192.168.4.0 255.255.255.0
next
edit 6
set dest-ip 192.168.198.0 255.255.255.0
next
edit 7
set dest-ip 192.168.2.0 255.255.255.0
next
edit 8
set dest-ip 192.168.22.0 255.255.255.0
next
edit 9
set dest-ip 10.10.10.0 255.255.255.0
next
edit 10
set dest-ip 192.168.106.0 255.255.255.0
next
end
set allowaccess telnet http https ssh
set login-passwd-change yes
set login-passwd ENC wqzlLrRoEfwv4MokVVYN5t6t1l4y/fS7ctUBCWqT58pPBtE+HsYbvHbNQ0bjxAFjn741Q4MLIMPtm5JbJnuh9NKEESzbG8gpE7j9oybru6x8EwnPcH1PHtC8k9jYjzxIpjZfFVvBjxNU4oe3bCUt9821BZNYyB5bfiTh62RRMKFN23ERDiQGIhbp/NbKlRTV1TU2pw==
config radio-1
set band 802.11n-only
set short-guard-interval enable
set auto-power-level enable
set auto-power-high 20
set auto-power-low 2
set wids-profile "ap-detection"
set vap-all disable
set vaps "MyFAP21"
set channel "1" "6" "11"
end
next
end
Anyway, I'm so happy because I'm going to Taipei within next few days for a month and now will be connected with my fap to my local infrastructure. :)
Cheers and Merry Christmas and upcoming Happy New Year!
//Sergey
Thank you Sergey for your great feedback and I will think any other possibility which prevents you from getting telnet to work. Have a great Holiday and Merry Christmas to you.
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 |
---|---|
1561 | |
1034 | |
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.