Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 1907 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
    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.
Reply
  • 0
    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.
Children
No Data