Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 1909 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

aste
Hi all,

I have a remote office where I want to route all traffic through Site-to-Site VPN. The setup was straight forward and everything works. But as soon as the tunnel is up, the remote ASG is inaccessable from the LAN at the remote office.

However, I can access it on the LAN IP from the central office through the VPN tunnel. In Network Security -> Packet Filter -> ICMP all the appropriate check boxes are marked.

If I disconnect the VPN tunnel, ASG is again accessible from the LAN.

Anyone seen this before and know how to solve it?


This thread was automatically locked due to age.
Parents
  • 0
    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?
Reply
  • 0
    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?
Children
  • 0 in reply to Ölm
    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
  • 0 in reply to 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
  • 0 in reply to Ölm
    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