LAN can't access ASG when /0 S2S VPN is up

Pretty sure not a bug but a routing issue.
A network plan or at least a more detailed explanaiton of your setup would be helpfull.
Which IP adresses, network masks, default GWs / static route are used on which of the two ASGs? How is you VPN setup configured?

Thank you for your reply, Ölm!

OKi, let's see:

Remote site
-----------
ASG LAN IP: 192.168.nn.2
IPSec VPN: Local Networks = Internal (Network) = 192.168.nn.0/24
IPSec VPN: Remote Networks = Any
Auto packet filter = on
Strict routing = on

Central site
-----------
ASG LAN IP: 192.168.kk.2
IPSec VPN: Local Networks = Any
IPSec VPN: Remote Networks = Remote Site = 192.168.nn.0/24
Auto packet filter = on
Strict routing = on

No static routes are setup on any site.
Remote site ASG can be accessed from Central Site on local IP and Internet on External IP.
If I change Remote site -> Remote Networks = Central Site LAN (192.168.kk.0/24) I can access Remote site ASG on local LAN IP from the remote LAN.

However, in both configurations the tunnel and routing between the sites works perfect.

I hope this clears the question marks!

BR
\ aste

Remote site ASG can be accessed from Central Site on local IP and Internet on External IP.
If I change Remote site -> Remote Networks = Central Site LAN (192.168.kk.0/24) I can access Remote site ASG on local LAN IP from the remote LAN.

However, in both configurations the tunnel and routing between the sites works perfect.

Ok , just to check wehether I have understood all correctly:
1) Routing over the VPN between  the two LANs 192.168.nn.0 and 192.168.kk.0 works fine, also access from 192.168.nn.0 to the Internet via the VPN tunnel (and via the central ASG) works fine?
2) if the tunnel is up, you cannot reach the remote ASG from the remote LAN, i.e. if you send ping packets from a PC in the 192.168.nn.0 network to the LAN IP of the ASG - 192.168.nn.2 - you don´t get answers?
but you get ping replies when 
3a) the tunnel is _not_  up
or
3b) you ping the same IP (192.168.nn.2) from a PC in the central LAN (192.168.kk.0) via the VPN ?


Is this correct? Sounds really strange.

Can you please post your routing table, first WITHOUT VPN established and second WITH VPN established?

You can find it under Support -> Advanced -> Routes Table

Hi Ölm,

All your points are correct.

Here's the routing table:

With the tunnel down
---------------------
10.1.0.0/16 dev ipsec0  table 42  proto 42  scope link  src 192.168.nn.2 
default via .41 dev eth1  table default  proto kernel onlink 
.40/29 dev eth1  proto kernel  scope link  src .43 
192.168.nn.0/24 dev eth0  proto kernel  scope link  src 192.168.nn.2 
198.19.250.0/24 dev eth3  proto kernel  scope link  src 198.19.250.1 
127.0.0.0/8 dev lo  scope link 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.nn.0 dev eth0  table local  proto kernel  scope link  src 192.168.nn.2 
local 192.168.nn.2 dev eth0  table local  proto kernel  scope host  src 192.168.nn.2 
broadcast 192.168.nn.255 dev eth0  table local  proto kernel  scope link  src 192.168.nn.2 
broadcast 198.19.250.0 dev eth3  table local  proto kernel  scope link  src 198.19.250.1 
local 198.19.250.1 dev eth3  table local  proto kernel  scope host  src 198.19.250.1 
broadcast 198.19.250.255 dev eth3  table local  proto kernel  scope link  src 198.19.250.1 
broadcast .40 dev eth1  table local  proto kernel  scope link  src .43 
local .43 dev eth1  table local  proto kernel  scope host  src .43 
local .43 dev ipsec0  table local  proto kernel  scope host  src .43 
broadcast .47 dev eth1  table local  proto kernel  scope link  src .43 
broadcast .47 dev ipsec0  table local  proto kernel  scope link  src .43 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 

With the tunnel up, these 2 lines are added as line 2 and 3
----------------------------------------------------------
0.0.0.0/1 dev ipsec0  table 42  proto 42  scope link  src 192.168.nn.2 
128.0.0.0/1 dev ipsec0  table 42  proto 42  scope link  src 192.168.nn.2 

Both sites are running v7.501. Could this be related to the same bug as Remote Access over SSL routing "Any" through the tunnel? But in that case, nothing came through the tunnel. Here, the tunnel works but the local interface gets unaccessible from LAN on the remote site.

\ aste

Hmm, strange. I have not much more ideas. The only interesting thing is that it seems you have divided the "any" routing entry (0.0.0.0/0) into two separate subnates 0.0.0.0/1 and 128.0.0.0/1, which of course should work, too, but perhaps it´s a problem somewhere..don´t know. I´d try to use the "any" object instead of the two objects and see what happens. 
ANd, of course, ionstall 7.502 ;-)

Here's a late follow up.
I did upgrade my boxes to 7.502. That didn't change anything.
I am using the default preconfigured Any object on both sides. This object obviously creates this split route.

Besides this, the remote site has 2 tunnels (as you might have seen in the routing table). We where having strange issues with connecting to terminal based, SNA authenticated sessions through that second tunnel. They could logon, but not do anything more. And only affecting some clients on the remote site, I didn't think it was a routing or communication issue. But hear this.

When removing the Any object from the other tunnel and replacing it with our 15 networks plus letting the Internet traffic go directly from the Remote network to Internet everything works. Local interface on remote site is reacheble (nothing new here) but also the terminal sessions worked(!?)

Somewhere I think something fundamental in routing functionality of the Astaro is not working as it should. Or it's not possible to use the Astaro as a "dumb" router/VPN gateway?

I have to test more...

Hm, seems the "split default route"  is making routing trouble.
 
To proof what happens, you could issue a "tcpdump -np -i *** icmp"  for any of the interfaces you own (i.e. make with XX=eth0, XX=eth1, XX=ipsec0, ...) and thus find out which way the echo requersts and the replies take. 
 
I also would give it a try to deactivate strict routing on the remote ASG ipsec tunnel. You probably don´t need it and I have seen some strange behaviour already with that. Perhaps the "strict" option makes the route higher priorized and thus the echo reply packets go "out" into the tunnel instead of back into the LAN.
 
About the terminal sessions: you don´t mean a RDP/Citrix based terminal session but a Telnet 3270 (or something else) session, right?
I´d suggest you have a look at the packet sizes of the incoming packets and whether they have the DF bit set. I suppose it´s a fragmentation problem. If yes, try to play with the ipsec and the outgoing interfaces MTU settings. Or try to deactivate the DF bit on the client side.