IKEv2 Connects but internet is very slow
-
My Setup
Brand new Netgate SG-3100 on 2.4.4 release 3
3 VLANs - Home, IOT and Guest
Using Resolver in forwarding mode with PFBlockerNG
Using a dynamic IP Address example.duckdns.orgClients are an iPhone SE and an iPad Air 2.
I followed the instructions at https://grokdesigns.com/pfsense-ikev2-for-ios-macos-1/ and am able to connect. When Phase 2 Local Network is set to Network 0.0.0.0/0 remote clients can access local computers and get the external IP of the server. However, internet access is very slow.
Things I have tried:
-Adding a domain override from the VPN's virtual address subnet to the address of the pfsense box.
-Turning off PFBlockerNGSeems like a DNS problem but I'm not sure what to do next to try to diagnose the issue.
-
Seems like a DNS problem but I'm not sure what to do next to try to diagnose the issue.
Debug DNS? What servers are the clients given, do the resolve names, etc.
There are some network diagnostic tools for iOS. Hurricane Electric maintains one called Network Tools, there is another one also called Network Tools, there is one called iNetTools.
In general when I need to troubleshoot something like this I would just connect to the IPsec using my macbook so I'd have a full suite of tools to use.
-
I have Network Analyzer Lite on my iphone. On its info page, I can see that the DNS Server is the address of my pfsense box and the external IP is the IP address of my WAN internet connection which is what I would expect. One thing I noticed that is not showing up is a block of information called VPN Information. That block of information is present when I connect via OpenVPN and alternatively when I turn off IPSEC in pfsense and forward the IPSEC ports to my Synology box and connect to its IPSEC VPN server. That VPN information contains IP Address (of the client), Subnet Mask and any IPv6 Addresses. Those two VPN configurations work well. When connected to the IKEv2 vpn at issue here, I can see in Settings/VPN/info for this particular configuration that it is getting an IP address from the virtual address pool configured in mobile clients.
Going over to HE tools, when I do a traceroute to google.com or yahoo.com Hop 1 just shows a "-" when connected to the IKEv2 vpn. On OpenVPN and Synology IPSEC, I see the ip address of the pfsense box in hop 1. After that its the same route.
The behavior I am seeing when trying to load a webpage is an initial long pause, then most of the page loads and the blue progress line in the address bar stops at about 40% across and then it appears to be trying to load more for a few minutes until it times out.
-
IDK. I would use a laptop to troubleshoot, not a phone.
-
I can try with my wife's macbook. What steps would you recommend?
-
General network troubleshooting. I would first use dig or drill to be sure the DNS configuration was sane and doing what it expected.
Look at the routing table to be sure it is sane.
Etc.
-
Dig and nslookup both work and are using the correct local address for DNS Resolver - 192.168.20.1
The routing table seems to be where the problem is.
10.7.4.1 is the Virtual Address Pool from Mobile Clients.
No idea where the 172.20.10.X stuff is coming from.
Next steps?
-
You'll have to talk to someone more familiar with Windows IKEv2 than I am.
-
This was from a macbook. Thanks for trying.
-
No need to get nasty.
The font threw me, and the fact that it's a screen shot instead of a copy/paste. We usually get that from Windows users.
-
No nasty intent at all, sorry if it came across that way. Was being sincere - I appreciate you taking the time to at least point me in the right direction.
-
What version of macos?
-
Mojave 10.14.5
Your font instincts were pretty good though. I output the netstat results to a file and then opened it in the text editor on my windows machine and when I tried to paste it to the forum the columns were all messed up so I went with a screenshot so it would be easily readable.
-
what is the output of:
scutil --dnswhen you are connected to the VPN? -
DNS configuration
resolver #1
nameserver[0] : 192.168.20.1
if_index : 16 (ipsec0)
flags : Request A records
reach : 0x00000002 (Reachable)resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300000resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300200resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300400resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300600resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300800resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 301000DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 172.20.10.1
if_index : 5 (en0)
flags : Scoped, Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)resolver #2
nameserver[0] : 192.168.20.1
if_index : 16 (ipsec0)
flags : Scoped, Request A records
reach : 0x00000002 (Reachable) -
So when you're connected to the VPN do both of these work quickly? (one sec)
dig @172.20.20.1 www.google.comdig @192.168.20.1 www.google.com -
dig @172.20.20.1 www.google.com
Connection Times Out
dig @192.168.20.1 www.google.com
Responds immediately <200ms
-
Just in case you had a typo I also ran
dig @172.20.10.1 www.google.com
this responded under 200ms as well.
-
Yeah that was a typo. Sorry. If both name servers respond in the same time frame (200ms is nothing to write home about) then I guess it's not DNS. If you do not NEED the clients to use a DNS server on the other side of the VPN, I don't think I would push it to them.
What, specifically, are you seeing?
-
My reason for pushing DNS to the other side is so that I can connect to machines on the other side using the hostnames stored in DNS Resolver and that part works. It's the internet connection that's the problem.
The thing that I can't get my head around is where is 172.20.10.1 coming from, as far as I know I didn't set it up.
-
The looks like the ethernet LAN on the client.
