Wireless Access

i try to use IAP and IAP-VPN with psk mode

vpn ikepsk sharedkey username myuser password mypassword

But the tunnel don't work (after 60sec -> retrying)

show vpn status


profile name:default
--------------------------------------------------
current using tunnel                            :primary tunnel
current tunnel using time                       :5 seconds 
ipsec is preempt status                         :disable
ipsec is fast failover status                   :disable
ipsec hold on period                            :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec     primary tunnel crypto type            :PSK
ipsec     primary tunnel peer address           :10.44.XX.XX
ipsec     primary tunnel peer tunnel ip         :1.1.1.127
ipsec     primary tunnel ap tunnel ip           :192.168.253.71
ipsec     primary tunnel using interface        :tun0
ipsec     primary tunnel using MTU              :1230
ipsec     primary tunnel current sm status      :Up
ipsec     primary tunnel tunnel status          :Up
ipsec     primary tunnel tunnel retry times     :2
ipsec     primary tunnel tunnel uptime          :5 seconds 

with cert mode, working

The peer ip is very strange (i get peer tunnel address with cert mode)

Any idea ?

the controller log :

Jun 29 19:41:19  authmgr[2218]: <522005> <INFO> |authmgr|  MAC=00:00:00:00:00:00 IP=192.168.253.65 User entry deleted: reason=idle timeout
Jun 29 19:41:19  authmgr[2218]: <522013> <INFO> |authmgr|  MAC=00:00:00:00:00:00 IP=192.168.253.65 IP DN: outerIP=10.44.Y.Y tunnels=9
Jun 29 19:41:19  isakmpd[2080]: <103056> <INFO> |ike|  IKE XAuth client down IP:192.168.253.65 External 10.44.Y.Y
Jun 29 19:41:39  authmgr[2218]: <124003> <INFO> |authmgr|  Authentication result=Authentication Successful(0), method=VPN, server=Internal, user=10.44.Y.Y 
Jun 29 19:41:39  authmgr[2218]: <124038> <INFO> |authmgr|  Reused server Internal for method=VPN; user=mysuser,  essid=<>, domain=<>, server-group=default
Jun 29 19:41:39  authmgr[2218]: <522006> <INFO> |authmgr|  MAC=00:00:00:00:00:00 IP=192.168.253.74 User entry added: reason=VPN
Jun 29 19:41:39  authmgr[2218]: <522008> <NOTI> |authmgr|  User Authentication Successful: username=mysuser MAC=00:00:00:00:00:00 IP=192.168.253.74 role=guest VLAN=0 AP=N/A SSID=N/A AAA profile=default auth method=VPN auth server=Internal
Jun 29 19:41:39  authmgr[2218]: <522012> <INFO> |authmgr|  MAC=00:00:00:00:00:00 IP=192.168.253.74 IP UP: outerIP=10.44.Y.Y tunnels=9
Jun 29 19:41:39  authmgr[2218]: <522017> <INFO> |authmgr|  MAC=00:00:00:00:00:00 IP=?? Derived role 'guest' from server rules: server-group=default, authentication=VPN
Jun 29 19:41:39  authmgr[2218]: <522038> <INFO> |authmgr|  username=mysuser MAC=00:00:00:00:00:00 IP=10.44.Y.Y Authentication result=Authentication Successful method=VPN server=Internal
Jun 29 19:41:39  authmgr[2218]: <522049> <INFO> |authmgr|  MAC=00:00:00:00:00:00,IP=0.0.0.0 User role updated, existing Role=none/none, new Role=logon/none, reason=IP user created
Jun 29 19:41:39  authmgr[2218]: <522049> <INFO> |authmgr|  MAC=00:00:00:00:00:00,IP=192.168.253.74 User role updated, existing Role=logon/none, new Role=logon/guest, reason=User authenticated with auth type:VPN client role derivation:0
Jun 29 19:41:39  authmgr[2218]: <522050> <INFO> |authmgr|  MAC=00:00:00:00:00:00,IP=10.44.Y.Y User data downloaded to datapath, new Role=logon/2, bw Contract=0/0, reason=IP up for non VPN transport for external user, idle-timeout=300
Jun 29 19:41:39  authmgr[2218]: <522050> <INFO> |authmgr|  MAC=00:00:00:00:00:00,IP=192.168.253.74 User data downloaded to datapath, new Role=guest/4, bw Contract=0/0, reason= IP up for non VPN transport, idle-timeout=300
Jun 29 19:41:39  isakmpd[2080]: <103015> <INFO> |ike|  IKE Main Mode Phase 1 succeeded for peer 10.44.Y.Y
Jun 29 19:41:39  isakmpd[2080]: <103022> <INFO> |ike|  IKE Quick Mode succeeded for peer 10.44.Y.Y
Jun 29 19:41:39  isakmpd[2080]: <103033> <INFO> |ike|  IKE Quick Mode succeeded internal 192.168.253.74, external 10.44.Y.Y
Jun 29 19:41:39  isakmpd[2080]: <103047> <INFO> |ike|  IKE XAuth succeeded for 192.168.253.74 (External 10.44.Y.Y) for guest
Jun 29 19:41:39  localdb[2253]: <133004> <INFO> |localdb|  Received Authentication Request for User mysuser
Jun 29 19:41:39  localdb[2253]: <133005> <INFO> |localdb|  User mysuser guest Successfully Authenticated

Hi,

I'm trying to establish VPN connection between StrongSwan and IAP.

I got this strange situation too.

Tunnel resets itself at every 45 seconds. There is not meaningful logs at StrongSwan side.

IAP gets "1.1.1.127" as ipsec primary tunnel peer tunnel ip. I asked this "1.1.1.127" IP at StrongSwan email group too. In conclusion, they said that this situation related with IAP.

Do you have any idea? I can send more logs from IAP if you need.

Thanks for help.

# show vpn status

profile name:default
--------------------------------------------------
current using tunnel :primary tunnel
current tunnel using time :19 seconds
ipsec is preempt status :disable
ipsec is fast failover status :disable
ipsec hold on period :600s
ipsec tunnel monitor frequency (seconds/packet) :5
ipsec tunnel monitor timeout by lost packet cnt :6

ipsec primary tunnel crypto type :PSK
ipsec primary tunnel peer address :X.X.X.X
ipsec primary tunnel peer tunnel ip :1.1.1.127
ipsec primary tunnel ap tunnel ip :10.99.0.10
ipsec primary tunnel using interface :tun0
ipsec primary tunnel using MTU :1230
ipsec primary tunnel current sm status :Up
ipsec primary tunnel tunnel status :Up
ipsec primary tunnel tunnel retry times :2
ipsec primary tunnel tunnel uptime :20 seconds

ipsec backup tunnel crypto type :PSK
ipsec backup tunnel peer address :N/A
ipsec backup tunnel peer tunnel ip :N/A
ipsec backup tunnel ap tunnel ip :N/A
ipsec backup tunnel using interface :N/A
ipsec backup tunnel using MTU :N/A
ipsec backup tunnel current sm status :Init
ipsec backup tunnel tunnel status :Down
ipsec backup tunnel tunnel retry times :0
ipsec backup tunnel tunnel uptime :0

Hi,

We have updated IAP image version from "6.5.1.0-4.3.1.2" to "6.5.3.4" and connection reset problem solved!

The root cause is IAP thinks StrongSwan as controller and making requests in every 3 seconds like:

2018-01-12 06:20:51 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 9, not-trusted: local-mgmt-mode
2018-01-12 06:20:54 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 10, not-trusted: local-mgmt-mode
2018-01-12 06:20:57 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 11, not-trusted: local-mgmt-mode
2018-01-12 06:21:00 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 12, not-trusted: local-mgmt-mode
2018-01-12 06:21:03 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 13, not-trusted: local-mgmt-mode
2018-01-12 06:21:06 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 14, not-trusted: local-mgmt-mode
2018-01-12 06:21:09 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 15, not-trusted: local-mgmt-mode
2018-01-12 06:21:12 [primary tunnel] ipsec_tunnel_monitor_action(2539): tunnel down be checked, controller 1.1.1.127
2018-01-12 06:21:12 [primary tunnel] tunnel_status_monitor_timeout(1085): monitor primary tunnel down, trigger state machine change.
2018-01-12 06:21:12 [primary tunnel] State TUNNEL_STATE_UP Event TUNNEL_EVENT_TUNNEL_DOWN Next state TUNNEL_STATE_DOWN
2018-01-12 06:21:12 [primary tunnel] tunnel_down(397): primary tunnel tunnel down.
2018-01-12 06:21:12 [primary tunnel] ipsec_tunnel_down(2063): Tunnel primary tunnel down.
2018-01-12 06:21:12 tunnel_set_status_to_asap(177): Set ipsec tunnel status =0 0

We still does not know why IAP peer tunnel ip is "1.1.1.127". IAP can not ping 1.1.1.127. (Probably it is normal)

When IAP making requests to "1.1.1.127" and can not access it marks the VPN connections as lost and resets the connection.

After upgrading to IAP image, IAP still makes connection requests to "1.1.1.127" but in every 1 minutes. (instead of every 3 seconds) Making requests in every 1 minute prevents IAP to mark VPN connections as down.

2018-01-12 07:30:13 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 41, not-trusted: local-mgmt-mode
 
2018-01-12 07:31:18 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 42, not-trusted: local-mgmt-mode
2018-01-12 07:32:25 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 43, not-trusted: local-mgmt-mode
2018-01-12 07:33:36 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 44, not-trusted: local-mgmt-mode
2018-01-12 07:34:50 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 45, not-trusted: local-mgmt-mode

Why IAP gets "1.1.1.127" as peer tunnel ip?

Why IAP making that request to "1.1.1.127"

The VPN connection logs about getting "1.1.1.127" as peer tunnel ip is:

2018-01-12 06:36:21 [primary tunnel] cli_proc_rapper_msg(864): Receive rapper msg from 59168 port.

2018-01-12 06:36:21 [cli_proc_rapper_msg] No Inner IP of Controller found. Its a non Aruba concentrator.Assgning the Concentrator's inner IP as 7f010101

2018-01-12 06:36:21 [primary tunnel] Received RC_OPCODE_PPP_UP lms XX.55.49.104 netmask 0.0.0.0 tunnel 10.99.0.1

2018-01-12 06:36:21 [primary tunnel] tunnel_up_msg_recv(1488): recv tunnel up msg, device tun0, rapper client port 8423, peer ip XX.55.49.104, tunnel ip 10.99.0.1 net mask 0.0.0.0, controller ip 1.1.1.127.

Hex to ip converter says that "7f010101" is "127.1.1.1" (Not 1.1.1.127)

Thanks for any help or comment.

Hi,

We have updated IAP version form "6.5.1.0-4.3.1.2" to "6.5.3.4" and connection reset problem solved.

Before upgrading IAP making requests to "1.1.1.127" in every 3 seconds:

2018-01-12 06:20:51 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 9, not-trusted: local-mgmt-mode
2018-01-12 06:20:54 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 10, not-trusted: local-mgmt-mode
2018-01-12 06:20:57 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 11, not-trusted: local-mgmt-mode
2018-01-12 06:21:00 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 12, not-trusted: local-mgmt-mode
2018-01-12 06:21:03 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 13, not-trusted: local-mgmt-mode
2018-01-12 06:21:06 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 14, not-trusted: local-mgmt-mode
2018-01-12 06:21:09 cli_rap_reg_request(3162) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 15, not-trusted: local-mgmt-mode
2018-01-12 06:21:12 [primary tunnel] ipsec_tunnel_monitor_action(2539): tunnel down be checked, controller 1.1.1.127
2018-01-12 06:21:12 [primary tunnel] tunnel_status_monitor_timeout(1085): monitor primary tunnel down, trigger state machine change.
2018-01-12 06:21:12 [primary tunnel] State TUNNEL_STATE_UP Event TUNNEL_EVENT_TUNNEL_DOWN Next state TUNNEL_STATE_DOWN
2018-01-12 06:21:12 [primary tunnel] tunnel_down(397): primary tunnel tunnel down.
2018-01-12 06:21:12 [primary tunnel] ipsec_tunnel_down(2063): Tunnel primary tunnel down.
2018-01-12 06:21:12 tunnel_set_status_to_asap(177): Set ipsec tunnel status =0 0

IAP can not ping the 1.1.1.127 (Probably it is normal?) After trying enough requests to 1.1.1.127, IAP marks VPN connection as down and resets the connection.

After upgrading IAP image version to 6.5.3.4, IAP still thinks StrongSwan as controller and making requests to "1.1.1.127" address in every 1 minutes. Frequency of this unsuccessful requests are decreased and this solved VPN connection reset problem.

2018-01-12 07:30:13 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 41, not-trusted: local-mgmt-mode
 
2018-01-12 07:31:18 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 42, not-trusted: local-mgmt-mode
2018-01-12 07:32:25 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 43, not-trusted: local-mgmt-mode
2018-01-12 07:33:36 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 44, not-trusted: local-mgmt-mode
2018-01-12 07:34:50 cli_rap_reg_request(3165) sending reg-request to 1.1.1.127 : iap/register?branch_key=bc3569e10117fdcaf2b8186220e32a72fc09f7a3604a9606f2&&subnet_count=0&is_backup=no&is_data_controller=no&is_trusted_branch=no&mac_addr=84d47ec4ce36&branch_name=central-demo with tun_idx 0 retry-counter 45, not-trusted: local-mgmt-mode

The logs about getting "1.1.1.127" as peer tunnel ip is:

2018-01-12 06:36:21 [primary tunnel] cli_proc_rapper_msg(864): Receive rapper msg from 59168 port.

2018-01-12 06:36:21 [cli_proc_rapper_msg] No Inner IP of Controller found. Its a non Aruba concentrator.Assgning the Concentrator's inner IP as 7f010101

2018-01-12 06:36:21 [primary tunnel] Received RC_OPCODE_PPP_UP lms X.55.49.104 netmask 0.0.0.0 tunnel 10.99.0.1

2018-01-12 06:36:21 [primary tunnel] tunnel_up_msg_recv(1488): recv tunnel up msg, device tun0, rapper client port 8423, peer ip X.55.49.104, tunnel ip 10.99.0.1 net mask 0.0.0.0, controller ip 1.1.1.127.

Why IAP gets "1.1.1.127" as ap peer tunnel ip?

Why IAP making requests to "1.1.1.127" (IAP thinks StrongSwan as controller?)

Logs say that "No Inner IP of Controller found. Its a non Aruba concentrator.Assgning the Concentrator's inner IP as 7f010101". Hex to ip conversion for "7f010101" is "127.1.1.1" (NOT 1.1.1.127)

Thanks for helps and any comments.

and the tunnel work ?

What your configuration ?

Yes, tunnel works.