Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 7 subscribers
  • Views 3599 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.
Parents
  • 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.

Reply
  • 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.

Children
No Data
Unfiltered HTML