ASG v6 to v7 - tunnel okay but no data transfer

This behaviour gets especially weird because another ipsec tunnel to another remote endpoint with dynamically assigned ip is working as always... traffic in both directions are okay - so what the heck can that be??
I tried around with compressing, strict routing, MTU sizes (on both sides) but nothing helps...

I would really really appreciate your help!!

Michael

Sounds like either the VPN is not really up (double check the VPN status on both ends) or there is a routing issue.

To verify, both subnets at each end of the VPN are unique?

Hi drees,

Sounds like either the VPN is not really up (double check the VPN status on both ends) or there is a routing issue.

To verify, both subnets at each end of the VPN are unique?

yes, both subnets are unique (one is 172.16.10.0/23 and the other is 172.99.0.0/16).
Both Astaro's say the tunnel is up and fine, the ASG6 as well as the ASG7.
I couldn't find any mistakes in the configuration, I did a triple check four times now!! I really checked every option you can set, and as I wrote, the tunnel is okay on both sides - as far as the ASG are telling me...

What can be wrong??

Michael

Please post the relevant section of the VPN Status page for the affected VPNs from both machines.

By unique, I mean those 2 VPN subnets don't overlap with any other subnets each firewall has defined, not that the 2 VPNs subnets are different from one another.

I assume that you have restarted the VPN on both ends to see if that helps? First grab the output from the VPN Status page, though.

Please post the relevant section of the VPN Status page for the affected VPNs from both machines.

By unique, I mean those 2 VPN subnets don't overlap with any other subnets each firewall has defined, not that the 2 VPNs subnets are different from one another.

I assume that you have restarted the VPN on both ends to see if that helps? First grab the output from the VPN Status page, though.

Hi drees,

Please post the relevant section of the VPN Status page for the affected VPNs from both machines.

This is the status from ASG 6 and 7, hope this is what you requested... [:)]


ASG v6 side (static IP, OOO'ed for security reasons)
-----------------------------------------------
000 "S_ipsec__vpnconn2_0": 172.16.10.0/23===OOO.OO.OOO.OOO...84.137.254.69===172.99.0.0/16; erouted; eroute owner: #1365
000 "S_ipsec__vpnconn2_0":     srcip=unset; dstip=unset; srcup=/opt/_updown.classic 2>/tmp/log 1>/tmp/log; dstup=/opt/_updown.classic 2>/tmp/log 1>/tmp/log;
000 "S_ipsec__vpnconn2_0":   ike_life: 7800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "S_ipsec__vpnconn2_0":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP; prio: 23,16; interface: eth1; 
000 "S_ipsec__vpnconn2_0":   dpd: action:restart; delay:30; timeout:120; 
000 "S_ipsec__vpnconn2_0":   newest ISAKMP SA: #1360; newest IPsec SA: #1365; 
000 "S_ipsec__vpnconn2_0":   IKE algorithms wanted: 5_000-1-5, flags=-strict
000 "S_ipsec__vpnconn2_0":   IKE algorithms found:  5_192-1_128-5, 
000 "S_ipsec__vpnconn2_0":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1536
000 "S_ipsec__vpnconn2_0":   ESP algorithms wanted: 3_000-1, ; pfsgroup=5; flags=-strict
000 "S_ipsec__vpnconn2_0":   ESP algorithms loaded: 3_000-1, ; pfsgroup=5; flags=-strict
000 "S_ipsec__vpnconn2_0":   ESP algorithm newest: 3DES_0-HMAC_MD5; pfsgroup=MODP1536
000  
000 #1365: "S_ipsec__vpnconn2_0":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1134s; newest IPSEC; eroute owner
000 #1365: "S_ipsec__vpnconn2_0" esp.a65f78b8@84.137.254.69 esp.4181fbcf@OOO.OO.OOO.OOO tun.109e@84.137.254.69 tun.109d@OOO.OO.OOO.OOO
000 #1360: "S_ipsec__vpnconn2_0":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1553s; newest ISAKMP; lastdpd=0s(seq in:17307 out:0)
-----------------------------------------------


ASG v7 side (dynamic IP T-Online)
-----------------------------------------------
[GREEN STATUS] vpncon  [1 of 1 SAs established]

[GREEN STATUS] SA:  172.99.0.0/16=84.137.254.69  OOO.OO.OOO.OOO=172.16.10.0/23
VPN ID: 84.137.254.69
IKE: Auth PSK / Enc 3DES_CBC_192 / Hash MD5 / Lifetime 7800s / PFS MODP1536 / DPD
IPSec: Enc 3DES_0 / Hash HMAC_MD5 / Lifetime 3600s
-----------------------------------------------

By unique, I mean those 2 VPN subnets don't overlap with any other subnets each firewall has defined, not that the 2 VPNs subnets are different from one another.

I do not really understand what you mean by overlapping - the 2 subnets are different (172.16.10/23 // 172.99/16) - I thought this is all what is a "must have" to get a working VPN... So eventually you could explain this a bit further??

I assume that you have restarted the VPN on both ends to see if that helps? First grab the output from the VPN Status page, though.

Of course, many times, not only the VPN, also both ASG's were restartet, the v6 ASG two times...

Michael

This is the status from ASG 6 and 7, hope this is what you requested... [[:)]]

Yep, looks OK.

I do not really understand what you mean by overlapping - the 2 subnets are different (172.16.10/23 // 172.99/16) - I thought this is all what is a "must have" to get a working VPN... So eventually you could explain this a bit further??

Your VPN subnets are fine. I am asking if you have any other subnets in those ranges on either firewall for any particular reason.

Of course, many times, not only the VPN, also both ASG's were restartet, the v6 ASG two times...

Had to ask. [[:)]]

When you ping the remote subnet from the other, do you see the packet counts climbing for the VPN when watching the VPN Routes page?

Do you have strict routing on/off and what about the auto packet filter? If the auto packet filter is off, do you have the appropriate packet filter rules set (though this shouldn't be affecting pings unless you disabled all the ping settings).

Hmm.... 172.99.x.x is not in the list of reserved internal IP addresses as defined by RFC 1918:  ftp://ftp.rfc-editor.org/in-notes/rfc1918.txt

I bet your problem is that the systems don't know where to route the packets.  Change that 172.99.x.x subnet to something that falls in the reserved IANA range -- I've seen this problem before with other routing / VPN Setups.  If that doesn't fix it, I don't know what it could be.

Valid Internal IP ranges:
10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

I bet your problem is that the systems don't know where to route the packets.  Change that 172.99.x.x subnet to something that falls in the reserved IANA range -- I've seen this problem before with other routing / VPN Setups.  If that doesn't fix it, I don't know what it could be.

That shouldn't matter. There's nothing keeping you from defining VPNs in public IP space, we do it all the time.

When the VPN is set up, it should route packets to that subnet via the VPN. And as the OP state originally, it used to work, but later stopped, so I suspect that something changed in his configuration that made this happen.

That very well may not be the reason for the problem in this case; however, I have in fact (it's been many moons ago) had customers with network problems, specifically with VPN tunnels and routing, due to public IP ranges being used on private networks.  The devices being used were trying to send packets to the "real" public hosts instead of the private ones.  Changing the subnet to a valid internal one fixed the issue, at least at 2 sites as I recall.  Just something to look at.

Hi BrucekConvergent,

Hmm.... 172.99.x.x is not in the list of reserved internal IP addresses as defined by RFC 1918:  ftp://ftp.rfc-editor.org/in-notes/rfc1918.txt

[...]

Valid Internal IP ranges:
10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

okay, I have to admit that I changed the ip address range from a valid one - for security reasons - to 172.99/16. Believe me that the real network *is* in the range of 172.16/12. I swear!! ;-)

So your approach could be right - but in my case it's not, sorry for the misunderstanding which I lead you into...

Michael

Well, that clears that up... have you restarted both systems on both ends of the tunnel?  Did this start after a recent update on either one?

Hi,

Well, that clears that up... have you restarted both systems on both ends of the tunnel?  Did this start after a recent update on either one?

Yes, as stated above, both systems were restarted. Not only the VPN, also the whole server...
I would have to lie if I would say I know if that happened *after* an update - because as I said above, it worked after creating the tunnel, but I have no idea if I made the update from 7.007 to 7.008+7.009 after creating the tunnel or before... sorry...
But it may be that this 7.009 update had an impact... I just don't know...

In the KB I saw a document regarding a problem with 3com network cards, but I don't think this applies to me, because I have another working VPN from the static v6 side to another dynamic ip endpoint with a netgear vpn-router as the endpoint (also site2site vpn) which is running absolutely perfect...

Michael

Hi drees,

sorry for answering so late, I had some other things to do (private).

Yep, looks OK.

Your VPN subnets are fine. I am asking if you have any other subnets in those ranges on either firewall for any particular reason.

Had to ask. [:)]

When you ping the remote subnet from the other, do you see the packet counts climbing for the VPN when watching the VPN Routes page?

Do you have strict routing on/off and what about the auto packet filter? If the auto packet filter is off, do you have the appropriate packet filter rules set (though this shouldn't be affecting pings unless you disabled all the ping settings).

1. no other subnets in those ranges
2. packet counter are climbing at the vpn status page on v6 side, don't know how to get this information on v7 side...
3. I tried strict routing on and off, no affect...
4. firewall rules are auto on both sides
5. icmp and traceroute - everything turned on - on both sides

Michael

2. packet counter are climbing at the vpn status page on v6 side, don't know how to get this information on v7 side...

Do they climb when you ping from both sides of the VPN?

Also, if you have a TCP port you can connect to on each end, can you attempt to connect to it, then use netstat to figure out if the remote end got the TCP syn packets or not?

This sounds like a DNAT or SNAT problem to me. Can you post your NAT rules?