[solved] Mobile stopped working after modem upgrade
-
Hi.
Since the upgrade to 2.2.5 my mobile IPSec configuration is not working anymore. The configuration is here attached, but I didn't change anything since before the upgrade.What appears strange to me is that the Android client returns Gateway is unreachable, tough OpenVPN in the very same condition connects instantly. Here's the strongswan's android log
Nov 13 08:01:50 00[DMN] Starting IKE charon daemon (strongSwan 5.3.3dr1, Linux 3.4.0-perf-g7337331, armv7l) Nov 13 08:01:50 00[LIB] loaded plugins: androidbridge charon android-log openssl fips-prf random nonce pubkey pkcs1 pkcs8 pem xcbc hmac socket-default eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls Nov 13 08:01:50 00[JOB] spawning 16 worker threads Nov 13 08:01:50 13[IKE] initiating IKE_SA android[14] to my.ipsec.host Nov 13 08:01:50 13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] Nov 13 08:01:50 13[NET] sending packet: from 10.12.217.144[54751] to my.ipsec.host[500] (1012 bytes) Nov 13 08:01:52 10[IKE] retransmit 1 of request with message ID 0 Nov 13 08:01:52 10[NET] sending packet: from 10.12.217.144[54751] to my.ipsec.host[500] (1012 bytes) Nov 13 08:01:55 09[IKE] retransmit 2 of request with message ID 0 Nov 13 08:01:55 09[NET] sending packet: from 10.12.217.144[54751] to my.ipsec.host[500] (1012 bytes) Nov 13 08:01:59 08[IKE] retransmit 3 of request with message ID 0 Nov 13 08:01:59 08[NET] sending packet: from 10.12.217.144[54751] to my.ipsec.host[500] (1012 bytes) Nov 13 08:02:05 07[IKE] giving up after 3 retransmits Nov 13 08:02:05 07[IKE] peer not responding, trying again (2/0) Nov 13 08:02:05 07[IKE] initiating IKE_SA android[14] to my.ipsec.host Nov 13 08:02:05 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ] Nov 13 08:02:05 07[NET] sending packet: from 10.12.217.144[54751] to my.ipsec.host[500] (1012 bytes) Nov 13 08:02:05 04[IKE] destroying IKE_SA in state CONNECTING without notification
Any hint is welcome! Thanks in advance
![screenshot-10.22.22.1 10443 2015-11-13 08-00-00.png](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-00-00.png)
![screenshot-10.22.22.1 10443 2015-11-13 08-00-00.png_thumb](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-00-00.png_thumb)
![screenshot-10.22.22.1 10443 2015-11-13 08-00-51.png](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-00-51.png)
![screenshot-10.22.22.1 10443 2015-11-13 08-00-51.png_thumb](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-00-51.png_thumb)
![screenshot-10.22.22.1 10443 2015-11-13 08-02-14.png](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-02-14.png)
![screenshot-10.22.22.1 10443 2015-11-13 08-02-14.png_thumb](/public/imported_attachments/1/screenshot-10.22.22.1 10443 2015-11-13 08-02-14.png_thumb) -
Client log indicates nothing is replying. Anything on the server-side IPsec log? I'm guessing not, as the likely scsenario that would lead to no reply means the traffic doesn't actually make it across (getting blocked by something, most often). Any blocks from the client's IP in your firewall logs?
-
@cmb:
Client log indicates nothing is replying. Anything on the server-side IPsec log? I'm guessing not, as the likely scsenario that would lead to no reply means the traffic doesn't actually make it across (getting blocked by something, most often). Any blocks from the client's IP in your firewall logs?
Indeed I forgot to mention I see nothing on the pfSense side, but I have other IPSec connection established.
I also got an upgrade of ISP's modem few days ago, I don't know if this could matter, but pfSense has a public IP (so bridged, no forwards) and it stopped working before that. -
disabled every firewall on the modem, restarted it over, ipsec working again :/
thanks anyway
-
Thanks for the follow up. The ones that were working had to have been initiators rather than responders in that case, as your modem likely was only blocking inbound, not outbound, traffic.