Wireless Access

Reply
Occasional Contributor II

IAP VPN to StrongSwan Strange AP Peer Tunnel IP

Hi,

 

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

 

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.

 

 # 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

 

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.

Occasional Contributor II

Re: IAP VPN to StrongSwan Strange AP Peer Tunnel IP

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.

 

 

 

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: