8.201 Firmware Broke our Site to site PBX ext calling using IAX Protocol

Pinging from TO PBX to NY PBX :
root@yyz-pbx-1:~ $
root@yyz-pbx-1:~ $ ping 10.20.8.1
PING 10.20.8.1 (10.20.8.1) 56(84) bytes of data.
From 10.20.0.254 icmp_seq=2 Destination Host Unreachable
From 10.20.0.254 icmp_seq=3 Destination Host Unreachable
From 10.20.0.254 icmp_seq=4 Destination Host Unreachable

--- 10.20.8.1 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3
root@yyz-pbx-1:~ $



Pinging from NY PBX to TO PBX 
root@jfk-pbx-1:~ $ ping 10.20.0.1
PING 10.20.0.1 (10.20.0.1) 56(84) bytes of data.
From 65.51.252.189 icmp_seq=1 Packet filtered
From 65.51.252.189 icmp_seq=2 Packet filtered
From 65.51.252.189 icmp_seq=3 Packet filtered
From 65.51.252.189 icmp_seq=4 Packet filtered
From 65.51.252.189 icmp_seq=5 Packet filtered

--- 10.20.0.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4003ms

A number of people have already reporting this same situation here.  What worked for one of them is to delete the site-to-site config on both sides and recreate from scratch.

Other than that if you are a paid license business user, you should open up a trouble ticket with Astaro Support.  If you have standard support, you have to go through your reseller.  If you have premium support, you can contact Astaro directly.  Astaro Support Hotline.

thanks Scott. I already opened a ticket with them... Our VPN is a bit more complex with multiple subsets and I am afraid of doing this all by myself.

If Support has a more granular fix, please post back with the results.  Right now on the boards, we're lacking a lot of information on workarounds for many of the issues in 8.200/201.

will do .. they are extremely slow to call me back.

Sort of the same issue here..

Just upgraded our walls to 8.201 and most of our tunnels work fine - however after spending most of the day scratching my head, changing rules etc I found this thread.

Funny part is its an IPSec tunnel between the offices in each end of the country, but only 1 subnet out of many stopped working. Green light is on, they can be cross pinged from other networks on both sides - just not from subnet to subnet in this case it is my DMZ and pretty critical since I got replicated webservers on DMZ1 and DMZ2..

[:@] it will be a very long night recreating this,..

yeah same with ours .. just one subnet with voice broke... thanks god it`s not the main one... but support it`s terrible .. opened a ticket 8 hours ago and they still didn`t get back to me.

same issue... subnet to subnet doesn`t work but I can ping from other subnet...

I see, sounds very identical..

Well keep me posted when you figure it out or support figures it out.
Likewise I will post if I should stumble upon a fix, so far pulling out the trouble subnet from the list of subnets in the tunnel and creating a new tunnel with only the trouble subnet did not work..

I fear this could end up being a everything from scratch..

I was solving similar issue with S2S after upgrade to 8.201 at one of customer boxes. Tunnel was up, SAs were up but communication was possible only in a one way direction.

I did solve it by adding a "No NAT" NAT rule (new feature of 8.200) for traffic entering the tunnel and everything started to work. Looks like that the ASG started to use masquerading rule to SNAT all the traffic - even the one that should go into the tunnel... Which it did not do on 8.103 or lower...

So maybe it is something worth looking into... [;)]

Nice find MBirdCZ.