Mobile IPSec VPN works but does not follow 302 redirects
-
This post is deleted! -
Looks like TCP is working fine to me. Not sure why that would help.
-
It's just a hypothesis.
I am very confused by the address 11.0.0.0 -
Clicking checkboxes without knowing why is how people get something checked that comes back to bite them later and is almost impossible to find.
-
This checkbox has already helped a lot of people. It is necessary to see the configuration of the topikstarter to understand whether it can help him or not (often the problem of checksum tcp is faced by the owners of realtek network cards)
But I also don't see any problems with tcp in packetcapture file -
@Konstanti @Derelict thanks a lot for looking through this.
11.0.0.0 is weird I agree, I just put this as the virtual IP address for client and when I generated an certificate (I followed this guide: https://www.netgate.com/docs/pfsense/vpn/ipsec/configuring-an-ipsec-remote-access-mobile-vpn-using-ikev2-with-eap-mschapv2.html) and connected with my Andriod phone this is the IP that it connects through.
Perhaps I did a mistake there? To my knowledge, I have not configured any NAT rules for the IPSec VPN server, see below. (Please note, I have my pfsense set up as a OpenVPN client, so there are some NAT rules but that is for a different VPN).
-
This is not entirely correct
It is better to assign addresses from the allowed list (private ip address)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16for example, 192.168.30.0/24
and then for this network, you can create a NAT outbound rule
for example ,
ipsec mobile client settings
and
nat outbound
-
This post is deleted! -
- You can open the strongswan app log and see which ip is assigned
or
2. /status/ipsec/leasesor
3. Status/System Logs/IPsec - You can open the strongswan app log and see which ip is assigned
-
@Konstanti Thanks man, I managed to reassign the virtual IP and set up the NAT as you mentioned, however it is still not working.
0_1549227415987_packetcapture_2.zip
I attach a new packet capture. Could it be something with the Unbound DNS Resolver? I am resolving the app1.example.com to IP 192.168.0.98 through pfsense Unbound DNS resolves. It works on all my other devices but is
there something special with IPSec VPN Mobile Clients? I read somewhere that I had to set the Outgoing Network Interfaces to LAN and Localhost for it to work over VPN, so did that already.DNS Resolver:
-
@svarto
Packetcapture file empty -
And don't filter on anything but the host address so we can see the DNS queries.
-
0_1549228302261_PacketCaptureontwointerfaces.zip
@Konstanti @Derelict I created two packetcaptures on the two separate interfaces, filtering for the android IPSec VPN client as Host (i.e. 192.168.200.1)
Should be something in the files now...
-
@Konstanti @Derelict What is very peculiar is that when I am connected to the Wifi on my phone, and then connect through the IPSec VPN. Everything works. When I am not on the internal network but on 4G on my phone, and connect through the IPSec VPN - it doesn't work.
See packetcapture from being on the Wifi and connected through VPN and everything works:
0_1549229309189_IPSecInterfaceonWifiallworks.zip -
Doesn't do any good to look at pcaps of it working without one of it not working to compare it to.
-
This post is deleted! -
@derelict said in Mobile IPSec VPN works but does not follow 302 redirects:
Doesn't do any good to look at pcaps of it working without one of it not working to compare it to.
I submitted two packet captures, one where it wasn't working (i.e. Android phone on 4G and the IPSec VPN turned on) and the second where it is working (i.e. Android phone on internal Wifi and the IPSec VPN turned on).
My problem is that I would expect it to work the same whenever I am connected through the IPSec VPN...
Or did I misunderstand your comment?
Please see below:
0_1549260318219_bothpacketcaptures.zip -
@svarto
Hey
Make two files on the lan interface (ipsec is not necessary)
The first, when works
Second , when not working
What you posted was an ipsec capture (workingpacketcapture.cap)
It looks like thisThe second file (Notworkingpacketcapture.cap) you already showed yesterday
This is yesterday's file (LanInterfaceClientasHost.cap)
-
@Konstanti Thanks for your patience, I did the packet captures for the two separate cases, attach them here in the .zip file and they are named according to if they were working or not:
-
And what is the error expressed ?
Visually, encrypted data is exchanged in both cases. There are no errors in the exchange. The client confirms receipt of the data.