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

Unfiltered HTML