IP switchs often to 85.17.225.221

[BKK20 0]

A lot of people face the same problem with AirVPN and their connection to a tracker. 

In the past everyone was connected with one exit IP:port to the tracker but since month the IP switchs between two different IPs.
One IP is the exit IP from the vpn server and the other IP is 85.17.225.221. Everyone seems to see this specific ip in their peer list.

Can someone explain why the exit IP change? Its really annoying and we are thinking to leave AirVPN.

 

[fishbasketballaries 16]

What server are you using? 85.17.225.221 does not belong to any AirVPN exit nodes.

[BKK20 0]

Menkalinan, but other user have the same problem with various server.

[fishbasketballaries 16]

Hmm, seems there may be a problem here. If I check my IP address using this site and this site, I can reliably get 85.17.225.221, but any other IP checkers (https://ipleak.net, https://icanhazip.com/, https://checkip.amazonaws.com/, https://ipinfo.io/ip) all show the correct exit address.  As far as I know, exit IP addresses should never change.

[BKK20 0]

Why is it like that? Why AirVPN never answered correctly what's the background about that and how to fix it?

[fishbasketballaries 16]

I'd be interested in hearing Staff's response as well. I'm not sure if we're allowed to tag them, but I don't see anything saying we can't, sooo @Staff 

[unn4m3d 2]

I am interested in this topic as well. Seems that NL servers are affected heavily. No problems so far with swiss servers, however this is a quick win not a solution for the problem. 

please investigate further @Staff

[toby103 0]

I have the same issue, please comment why exit ip is changing and how this can be circumvented.

[OpenSourcerer 1360]

Positive sample first: After the gateway it stays in M247 space most of the time, then gets handed off to what appears to be Cloudflare's Netherlands IX until finally arriving at the destination.

# traceroute -T icanhazip.com
traceroute to icanhazip.com (104.18.115.97), 30 hops max, 60 byte packets
1  10.27.6.1 (10.27.6.1)  11.186 ms  11.769 ms  11.774 ms
2  vlan27.as11.fra4.de.m247.com (141.98.102.177)  12.033 ms  12.152 ms  12.392 ms
3  vlan2919.agg2.fra4.de.m247.com (212.103.51.150)  11.761 ms  11.998 ms  12.004 ms
4  37.120.220.117 (37.120.220.117)  12.389 ms  12.388 ms  12.386 ms
5  193.27.15.223 (193.27.15.223)  11.994 ms 37.120.128.129 (37.120.128.129)  21.342 ms 37.120.128.253 (37.120.128.253)  12.092 ms
6  cloudflare.equinix-fr4.nl-ix.net (193.239.118.138)  13.699 ms  13.936 ms  12.635 ms
7  104.18.115.97 (104.18.115.97)  23.921 ms 172.70.248.3 (172.70.248.3)  12.412 ms 172.70.244.3 (172.70.244.3)  12.928 ms

---

Negative sample: There is a redirection happening to another private v4 directly after the gateway, then through Leaseweb space until the handoff to Cloudflare at hop 8. Interesting detail, that redirection…

traceroute -T iplocation.net
traceroute to iplocation.net (188.114.97.10), 30 hops max, 60 byte packets
1  10.27.6.1 (10.27.6.1)  10.888 ms  10.888 ms  11.110 ms
2  10.252.128.1 (10.252.128.1)  19.355 ms  19.609 ms  19.611 ms
3  85.17.225.252 (85.17.225.252)  20.100 ms  20.102 ms  20.272 ms
4  po-123.ce16.ams-01.nl.leaseweb.net (212.7.201.132)  20.349 ms po-123.ce15.ams-01.nl.leaseweb.net (212.7.201.128)  20.270 ms  20.346 ms
5  81.17.35.64 (81.17.35.64)  20.832 ms  20.833 ms 81.17.35.60 (81.17.35.60)  20.576 ms
6  po-117.agg01.ams-01.leaseweb.net (31.31.38.40)  20.569 ms po-117.agg02.ams-01.leaseweb.net (31.31.38.44)  19.026 ms po-118.agg02.ams-01.leaseweb.net (31.31.38.46)  19.262 ms
7  et-49-1.agg01.ams-01.leaseweb.net (31.31.34.200)  19.498 ms et-49-1.bb01.fra-13.leaseweb.net (31.31.34.53)  26.650 ms  26.536 ms
8  162.158.84.10 (162.158.84.10)  27.514 ms  30.762 ms et-53-1.bb01.fra-13.leaseweb.net (31.31.34.51)  26.500 ms
9  172.70.244.3 (172.70.244.3)  27.738 ms 172.70.248.3 (172.70.248.3)  27.962 ms  27.960 ms
10  172.70.240.3 (172.70.240.3)  27.704 ms  27.602 ms 188.114.97.10 (188.114.97.10)  27.861 ms

---

Second negative sample: Find the difference in these pictures…

traceroute -T whatsmyip.com
traceroute to whatsmyip.com (188.114.96.3), 30 hops max, 60 byte packets
 1  10.27.6.1 (10.27.6.1)  11.139 ms  11.165 ms  11.165 ms
 2  10.252.128.1 (10.252.128.1)  19.192 ms  19.440 ms  19.445 ms
 3  85.17.225.252 (85.17.225.252)  19.675 ms  19.866 ms  19.885 ms
 4  po-123.ce15.ams-01.nl.leaseweb.net (212.7.201.128)  19.845 ms  19.854 ms  19.873 ms
 5  81.17.35.60 (81.17.35.60)  20.143 ms 81.17.35.62 (81.17.35.62)  20.390 ms 81.17.35.58 (81.17.35.58)  20.370 ms
 6  po-118.agg01.ams-01.leaseweb.net (31.31.38.42)  20.129 ms  19.202 ms  19.197 ms
 7  et-49-1.bb01.fra-13.leaseweb.net (31.31.34.53)  26.684 ms  26.388 ms et-50-1.agg01.fra-10.leaseweb.net (31.31.34.29)  26.145 ms
 8  162.158.84.10 (162.158.84.10)  28.820 ms  28.846 ms  29.111 ms
 9  162.158.84.10 (162.158.84.10)  29.117 ms 172.70.248.3 (172.70.248.3)  28.810 ms 162.158.84.10 (162.158.84.10)  28.353 ms
10  172.70.248.3 (172.70.248.3)  27.594 ms 188.114.96.3 (188.114.96.3)  28.788 ms  28.586 ms

… they're the same pictures! Well, not exactly, but you'll notice a striking similarity.

---

10.252.128.1. This redirection is all that causes the ghost IP change. And it must be AirVPN-internal because there is no other explanation for a private v4 gateway followed by another private v4 address in the next hop. It ends up in a subnet from LeaseWeb in hop 3, and I believe the NL rerouting server is a LeaseWeb server (that's where the IP address you see comes from).

Does the server IP address change? No.
Is there a cause for concern? I strongly disagree.
Should Staff be informed? I think so. At least to check on whether there are rerouting rules for these IP APIs.
 

On 5/4/2022 at 11:22 PM, BKK20 said:

Its really annoying and we are thinking to leave AirVPN.

Don't panic.
 

On 5/5/2022 at 3:08 AM, fishbasketballaries said:

85.17.225.221 does not belong to any AirVPN exit nodes.

None you can directly connect to, no. Though, strictly speaking, a request rerouted through a rerouting server makes that rerouting server a de-facto exit node.
 

On 5/5/2022 at 8:10 AM, BKK20 said:

Menkalinan, but other user have the same problem with various server.

Provide a list of servers and optionally a list of users reporting that.
 

On 5/5/2022 at 10:52 AM, fishbasketballaries said:

Hmm, seems there may be a problem here.

Probably a misconfiguration instead.
 

On 5/5/2022 at 10:52 AM, fishbasketballaries said:

As far as I know, exit IP addresses should never change.

They don't.
 

On 5/6/2022 at 9:58 PM, BKK20 said:

Why AirVPN never answered correctly what's the background about that and how to fix it?

Staff don't read every thread.
 

8 hours ago, toby103 said:

please comment why exit ip is changing and how this can be circumvented.

See above, and by not panicking.
 

On 5/9/2022 at 8:33 PM, unn4m3d said:

Seems that NL servers are affected heavily.

Provide a list of servers you observed showing this IP API result.

[toby103 0]

7 hours ago, OpenSourcerer said:

Positive sample first: After the gateway it stays in M247 space most of the time, then gets handed off to what appears to be Cloudflare's Netherlands IX until finally arriving at the destination.

# traceroute -T icanhazip.com
traceroute to icanhazip.com (104.18.115.97), 30 hops max, 60 byte packets
1  10.27.6.1 (10.27.6.1)  11.186 ms  11.769 ms  11.774 ms
2  vlan27.as11.fra4.de.m247.com (141.98.102.177)  12.033 ms  12.152 ms  12.392 ms
3  vlan2919.agg2.fra4.de.m247.com (212.103.51.150)  11.761 ms  11.998 ms  12.004 ms
4  37.120.220.117 (37.120.220.117)  12.389 ms  12.388 ms  12.386 ms
5  193.27.15.223 (193.27.15.223)  11.994 ms 37.120.128.129 (37.120.128.129)  21.342 ms 37.120.128.253 (37.120.128.253)  12.092 ms
6  cloudflare.equinix-fr4.nl-ix.net (193.239.118.138)  13.699 ms  13.936 ms  12.635 ms
7  104.18.115.97 (104.18.115.97)  23.921 ms 172.70.248.3 (172.70.248.3)  12.412 ms 172.70.244.3 (172.70.244.3)  12.928 ms

---

Negative sample: There is a redirection happening to another private v4 directly after the gateway, then through Leaseweb space until the handoff to Cloudflare at hop 8. Interesting detail, that redirection…

traceroute -T iplocation.net
traceroute to iplocation.net (188.114.97.10), 30 hops max, 60 byte packets
1  10.27.6.1 (10.27.6.1)  10.888 ms  10.888 ms  11.110 ms
2  10.252.128.1 (10.252.128.1)  19.355 ms  19.609 ms  19.611 ms
3  85.17.225.252 (85.17.225.252)  20.100 ms  20.102 ms  20.272 ms
4  po-123.ce16.ams-01.nl.leaseweb.net (212.7.201.132)  20.349 ms po-123.ce15.ams-01.nl.leaseweb.net (212.7.201.128)  20.270 ms  20.346 ms
5  81.17.35.64 (81.17.35.64)  20.832 ms  20.833 ms 81.17.35.60 (81.17.35.60)  20.576 ms
6  po-117.agg01.ams-01.leaseweb.net (31.31.38.40)  20.569 ms po-117.agg02.ams-01.leaseweb.net (31.31.38.44)  19.026 ms po-118.agg02.ams-01.leaseweb.net (31.31.38.46)  19.262 ms
7  et-49-1.agg01.ams-01.leaseweb.net (31.31.34.200)  19.498 ms et-49-1.bb01.fra-13.leaseweb.net (31.31.34.53)  26.650 ms  26.536 ms
8  162.158.84.10 (162.158.84.10)  27.514 ms  30.762 ms et-53-1.bb01.fra-13.leaseweb.net (31.31.34.51)  26.500 ms
9  172.70.244.3 (172.70.244.3)  27.738 ms 172.70.248.3 (172.70.248.3)  27.962 ms  27.960 ms
10  172.70.240.3 (172.70.240.3)  27.704 ms  27.602 ms 188.114.97.10 (188.114.97.10)  27.861 ms

---

Second negative sample: Find the difference in these pictures…

traceroute -T whatsmyip.com
traceroute to whatsmyip.com (188.114.96.3), 30 hops max, 60 byte packets
 1  10.27.6.1 (10.27.6.1)  11.139 ms  11.165 ms  11.165 ms
 2  10.252.128.1 (10.252.128.1)  19.192 ms  19.440 ms  19.445 ms
 3  85.17.225.252 (85.17.225.252)  19.675 ms  19.866 ms  19.885 ms
 4  po-123.ce15.ams-01.nl.leaseweb.net (212.7.201.128)  19.845 ms  19.854 ms  19.873 ms
 5  81.17.35.60 (81.17.35.60)  20.143 ms 81.17.35.62 (81.17.35.62)  20.390 ms 81.17.35.58 (81.17.35.58)  20.370 ms
 6  po-118.agg01.ams-01.leaseweb.net (31.31.38.42)  20.129 ms  19.202 ms  19.197 ms
 7  et-49-1.bb01.fra-13.leaseweb.net (31.31.34.53)  26.684 ms  26.388 ms et-50-1.agg01.fra-10.leaseweb.net (31.31.34.29)  26.145 ms
 8  162.158.84.10 (162.158.84.10)  28.820 ms  28.846 ms  29.111 ms
 9  162.158.84.10 (162.158.84.10)  29.117 ms 172.70.248.3 (172.70.248.3)  28.810 ms 162.158.84.10 (162.158.84.10)  28.353 ms
10  172.70.248.3 (172.70.248.3)  27.594 ms 188.114.96.3 (188.114.96.3)  28.788 ms  28.586 ms

… they're the same pictures! Well, not exactly, but you'll notice a striking similarity.

---

10.252.128.1. This redirection is all that causes the ghost IP change. And it must be AirVPN-internal because there is no other explanation for a private v4 gateway followed by another private v4 address in the next hop. It ends up in a subnet from LeaseWeb in hop 3, and I believe the NL rerouting server is a LeaseWeb server (that's where the IP address you see comes from).

Does the server IP address change? No.
Is there a cause for concern? I strongly disagree.
Should Staff be informed? I think so. At least to check on whether there are rerouting rules for these IP APIs.
 
Don't panic.
 
None you can directly connect to, no. Though, strictly speaking, a request rerouted through a rerouting server makes that rerouting server a de-facto exit node.
 
Provide a list of servers and optionally a list of users reporting that.
 
Probably a misconfiguration instead.
 
They don't.
 
Staff don't read every thread.
 
See above, and by not panicking.
 
Provide a list of servers you observed showing this IP API result.

Thank you for that detailed explanation. Looking forward to a statement from AirVPN and fix of their configuration.

[BKK20 0]

When do we get a explanation from @Staff?
We are not connectable because of the  IP switch.

[Staff 9764]

Hello!

The problem is caused by the micro-routing feature, especially if the tracker is in a CDN and therefore might be reached on different IP  addresses, some of them micro-routed and some of them not micro-routed. Consider to use DHT and avoid those trackers at the moment. DHT makes trackers redundant and obsolete, they are zombies kept alive only for "private torrenting" purposes. In the meantime we will consider to offer an option to disable micro-routing.

Kind regards
 

[unn4m3d 2]

On 5/13/2022 at 11:26 AM, Staff said:

Hello!

The problem is caused by the micro-routing feature, especially if the tracker is in a CDN and therefore might be reached on different IP  addresses, some of them micro-routed and some of them not micro-routed. Consider to use DHT and avoid those trackers at the moment. DHT makes trackers redundant and obsolete, they are zombies kept alive only for "private torrenting" purposes. In the meantime we will consider to offer an option to disable micro-routing.

Kind regards
 

This is not the answer I was expecting from @Staff of a VPN service whose values are defence of net neutrality, privacy and against censorship.
Please doublecheck NL server configurations. Many thanks. 

[Staff 9764]

@unn4m3d
@BKK20
 

Quote

This is not the answer I was expecting from @Staff of a VPN service whose values are defence of net neutrality, privacy and against censorship.
Please doublecheck NL server configurations. Many thanks. 

Your consideration can not be agreed upon, as micro-routing fights censorship as well as end-to-end connectivity principle infringements by bypassing, when possible, third-party blocks.

We are seriously considering to offer an option to disable micro-routing. Remember that those trackers (and any service in general) which block our NL VPN servers will become completely unreachable with micro-routing disabled.