Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 7 subscribers
  • Views 3598 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WiFi Radius over IPSec

SebK

Hi there, 

I´m having a hard time understanding some RADIUS authentication issues. 

For better understanding, a sketch of my setup:

We have a UTM with Wireless Protection in the Head Office. We have a running Authentification with RADIUS for some APs there, which works fine.

We have a Guest Network with WPA2 PSK Authentification and an Internal Net with RADIUS Authentication (by MS NPS Server).

1. To test RADIUS over IPSEC i build a Testsetup within our LAN. So the aWAN Interface of the XG gets a IP in the Client Network an builds up it´s IPSec Tunnels.

To register the AP in the "Testbranch Office" I setup the DHCP Server for the AP with the DHCP Option 234 "Magic IP", pointing at the listening Interface of the UTM (192.168.250.254)

Everything works like a charm. The Config is posted to the AP and both SSIDs work like expected.

Now the Problem:

I took the whole Branch Office Setup (XG, VLAN Switch, AP and the Laptop) which are working in the internal Network and place it behind a real WAN Connection.

Guess what, the WPA PSK Setup is working, but the RADIUS Authentification runs in a time-out.

The TCP Dump of a working connection (in the internal Testsetup) looks like this: AP-> 414 -> Magic IP and backwards

The Request is send to the RADIUS and shows up in the logs.

In the WAN Setup there is no Log entry in at the RADIUS Log. I can see this in the wirless log:

2021:10:11-21:06:27 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.11: disassociated
2021:10:11-21:06:27 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.11: Unspecified error (code:1)
2021:10:11-21:06:29 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.11: associated
2021:10:11-21:06:30 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.1X: STA identity 'host/ELP1592.domain.name'
2021:10:11-21:06:30 P52003WXK26WP35 kernel: [ 7863.837823] [wifi1] FWLOG: [2722079] RATE: ChainMask 3, peer_mac 83:ae, phymode 9, ni_flags 0x0203b006, vht_mcs_set 0xfffa, ht_mcs_set 0xffff, legacy_rate_set 0x0ff0
2021:10:11-21:06:30 P52003WXK26WP35 kernel: [ 7863.837865] [wifi1] FWLOG: [2722079] RTT_REPORT ( 0x2804, 0x3, 0x479, 0x0, 0x9 )
2021:10:11-21:06:35 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.1X: ieee_802_1x auth failed (code:23)
2021:10:11-21:06:35 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.11: disassociated
2021:10:11-21:06:35 P52003WXK26WP35 hostapd: ath100: STA 44:03:2c:91:83:ae IEEE 802.11: Disassoc - ieee_802_1x auth failed (code:23)
The Packet Captures shows that AP and Magic IP are "talking" with Ports 415 and 2127 but the response to the 414 (RADIUS Request) is an ICMP Error Type 3 Code 3 (Destination Port Unreachable) from the Magic IP. 

2021-10-11 21:06:33Firewallmessageid="00005" log_type="Firewall" log_component="ICMP ERROR MESSAGE" log_subtype="Allowed" status="Allow" con_duration="0" fw_rule_id="5" nat_rule_id="0" policy_type="1" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" vlan_id="" ether_type="IPv4 (0x0800)" bridge_name="" bridge_display_name="" in_interface="ipsec0" in_display_interface="ipsec0" out_interface="" out_display_interface="" src_mac="f0:af:85:9a:ee:8f" dst_mac="" src_ip="192.168.250.254" src_country="R1" dst_ip="192.168.251.10" dst_country="R1" protocol="ICMP" icmp_type="3" icmp_code="3" packets_sent="0" packets_received="0" bytes_sent="0" bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="LAN" src_zone="LAN" dst_zone_type="" dst_zone="" con_direction="" con_event="Interim" con_id="3222778674" virt_con_id="" hb_status="No Heartbeat" message="" appresolvedby="Signature" app_is_cloud="0"

I don´t understand the difference.

I read about the NAT Rule for WAN Interface etc. but the WAN IP isn´t talking to the UTM. I can see, that the AP is talking to the Magic IP and the UTM forwards the request to the RADIUS an back to the AP.

So the communication should use Port 414 between AP and Magic IP(UTM) and this happens and works in the Test Setup. 

What am I missing?!

Thanks in advance!



This thread was automatically locked due to age.
  • 0

    Sorry for the typos and the wrong Magic IP in the sketch. Of course it´s 192.168.250.254

  • +1

    Hallo and welcome to the UTM Community!

    This question is too complex to ask here.  I don't imagine that one of us volunteers will have an hour to study this.  Also, it looks like this is more of an XG question than UTM, but, as I said, I don't know where the question is.  Maybe post a simpler question in the XG Community???

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hey Bob,

    Thanks for your response and your feedback. 

    Since the UTM is the "Wireless Controller" I thought this might fit in here. I registered for the UTM Support, to get some one look into this.

    Maybe fo anyone stumbling across this, I try it in a shorter way:

    Following this Documentation onlinehelp (sophos.com) the AP uses Port 414 to pass RADIUS Requests to the "Wireless Controller" or Magic IP.

    In my case this works fine in a LAN bound Test Enviroment, but not in the real world.

    So the difference is the WAN IP between Test Setup (working) and Real Life (not working) the WAN Interface.

    Test Environment WAN IP = Private IP, locally routed. Real World WAN IP = public IP, globally routed.

    Still all traffic is moving through the IPSec Tunnel.

    I don´t understand why the RADIUS Request is timing out, if the WAN Interface uses a public IP.

    I thought some could point out another difference that I don´t know or had similar issues with that setup.

  • 0

    I could solve the Problem with the help of our Sophos Partner

    To make RADIUS work over IPSec, beside the DHCP 234 option, you need to add your WAN Interface to the Wireless Access Control List in the Global Settings.

    The UTM checks the incomming interface. Because the IPSEC Tunnel is bound to the WAN Interface, the packets are dropped if the WAN Interface is not in the Access Control List.

    I guess this is not recommended for security reasons to do that. So if you have a chance you should switch to RED Interfaces.

    If you know this you´ll find several Threads reffering to this "problem", e.g.

    Sophos WLAN AP over VPN - Wireless Security - UTM Firewall - Sophos Community

    I still wonder why AP Traffic is working without any issues if the WAN Interface is not allowed in the Access List. I thought this would have been dropped too, but there a no issues with this setting in general. Only when it comes to RADIUS Authentification the Problem shows up.

    Anyway, maybe it´s usefull for anyone to know this.

  • 0

    Hey Bob,

    SNAT For Radius via IPsec - Network Protection: Firewall, NAT, QoS, & IPS - UTM Firewall - Sophos Community

    I found this Thread and see some similarities to my situation. Did you get your Problem solved back then?

    I wonder if an SNAT Rule could change the source Interface which is checked by the ACL of Wireless Protection?!

    Thanks in Advance!

    Sebastian

  • 0 in reply to SebK

    Interesting, Sebastian - I don't remember getting a PM from him, but my guess would be that the SNAT trick might work for you.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0

    To close this Thread:

    I got an detailed answer from the 3rd Level Support regarding the funtionality of this whole thing.

    As I mentioned above the UTM an IPSec Tunnel is bound to the WAN Interface and has no own (virtual) Interface which can be used to put it in the "allowed list". 

    The last question was, why the UTM is able to handle the Management traffic (AWE traffic (Port 2712) and AP Log Traffic (Port 415)) perfectly fine, but can´t handle the RADIUS Requests (port 414)

    The AWE traffic (Port 2712) and AP Log Traffic (Port 415) is addressed directly to the UTM, so the UTM can handle this after decryption on the WAN Interface with the resp. listeners.

    Since there is no listener for the IPSec Interface - the Traffic isn´t intercepted by the UTM and is dropped by the Kernel. Kernel Drops can´t be seen in any Logs. So no one found (from us) any hints why the traffic just dissapeared. This is changing if you put the WAN Interface to the "Allowed" List, because the listener can handle the traffic after decryption.

    Security Consideration:
    From Sophos 3rd Level Point of view there should be no security issued and the setup (WAN Interface in allowed list) is considered as supported setup.

    Hope this helps someone.

  • 0 in reply to Ali Razza

    Hey Ali Razzy,

    please open a new Thread to keep things clean. I´ll post my "little" amount of knowlede, I promise.

Unfiltered HTML