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

IPSec Site2Site VPN Using Cisco C2800/C2900 and SG115 can't communicate eachother.

Hi

I setup Site-to-site VPN by IPSec using C2821 and SG115.
It looks like to be connected from looking Site-to-site VPN Tunnel Status.
but, it can't response by ping ,eachother.
And ,this situation is reproducted when using C2921 instead of C2821.

don't you have any ideas that I should do to solve this trouble? please.


[Base information: IP address]
  Cisco's connected Grobal IP adress  : 10.10.10.10
  Cisco sides Local IP address            : 192.168.14.0/24
  SG115's connected Grobal IP adress : 20.20.20.20 
  SG115 sides Local IP address           : 192.168.3.0/24

[config of C2800]
crypto isakmp policy 1
encr aes 256
hash md5
authentication pre-share
group 5
lifetime 7800
crypto isakmp key pre-share-Key address 20.20.20.20 no-xauth
!
!
crypto ipsec transform-set TUNNEL1 esp-aes 256 esp-md5-hmac
!
crypto map TUNNEL 10 ipsec-isakmp
set peer 20.20.20.20
set transform-set TUNNEL1
set pfs group5
match address 102
!
interface GigabitEthernet0/0
no ip address
ip nbar protocol-discovery
ip virtual-reassembly max-reassemblies 128
duplex auto
speed 100
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface GigabitEthernet0/1
ip address 192.168.14.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface Dialer0
ip address negotiated
ip nat outside
ip virtual-reassembly max-reassemblies 1024
encapsulation ppp
ip tcp adjust-mss 1398
dialer pool 1
dialer idle-timeout 0
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname ************.net
ppp chap password 0 ***********
crypto map TUNNEL

access-list 102 permit ip 192.168.14.0 0.0.0.255 192.168.3.0 0.0.0.255

 

[SG115 Setting]

Using Default policy [AES 256 PFS] and Setting RemoteGateway like this.

 

[Live Log of SG115]

2017:04:09-12:16:05 kpr002 pluto[2976]: "S_CiscoVPNConnection" #305: ignoring informational payload, type NO_PROPOSAL_CHOSEN
2017:04:09-12:17:15 kpr002 pluto[2976]: "S_CiscoVPNConnection" #341: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2017:04:09-12:17:15 kpr002 pluto[2976]: "S_CiscoVPNConnection" #341: starting keying attempt 338 of an unlimited number
2017:04:09-12:17:15 kpr002 pluto[2976]: "S_CiscoVPNConnection" #342: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #341 {using isakmp#305}
2017:04:09-12:17:16 kpr002 pluto[2976]: "S_CiscoVPNConnection" #342: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
2017:04:09-12:17:16 kpr002 pluto[2976]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="CiscoVPNConnection" address="116.58.175.67" local_net="192.168.3.0/24" remote_net="192.168.14.0/24"
2017:04:09-12:17:16 kpr002 pluto[2976]: "S_CiscoVPNConnection" #342: sent QI2, IPsec SA established {ESP=>0xe6dadc37 <0x2215776e DPD}
2017:04:09-13:03:17 kpr002 pluto[2976]: "S_CiscoVPNConnection" #343: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP to replace #342 {using isakmp#305}
2017:04:09-13:03:18 kpr002 pluto[2976]: "S_CiscoVPNConnection" #343: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
2017:04:09-13:03:18 kpr002 pluto[2976]: "S_CiscoVPNConnection" #343: sent QI2, IPsec SA established {ESP=>0xf4695a03 <0x22294345 DPD}


This thread was automatically locked due to age.
Parents
  • Hi, 聡, and welcome to the UTM Community!

    It looks like the connection is made successfully, so something, somewhere is blocking packets or incorrectly routing them.  When faced with such a mystery, do #1 in Rulz.

    It's important to note that pinging is regulated on the 'ICMP' tab of 'Firewall' and that the "Any" Service includes only TCP and UDP, not any of the other IP protocols.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thank you for your reply.

    First let me refer to it.

    Currently, GRI is set from CUI,
    For the time being we made it possible to communicate.

    First of all, we propose to customers with this configuration,
    After deployment at the customers office, I will rechallenge it using my test machine.

    After the challenge, I will write it again once the cause is known.
    Thank you everyone.

  • Hi,

    How do you made it possible to communicate?

    i am facing to the same issue

    i need help please since 3 weeks

Reply Children
  • Hi

    In my case, I used GRE Tunnnel by executing the following command after ssh login.

    And add static route record.

    [CUI]
    iptunnel add tun1 mode gre remote 10.10.10.10 local 20.20.20.20 ttl 255
    ifconfig tun1 inet 192.168.254.2 netmask 255.255.255.0

    [GUI]
    interface & rouing> static routing
    NW: 192.168.14.0
    GW: 192.168.254.1

    Of course, the C2821 side has the following settings as GRE tunnel.
    [CUI: C2821]
    interface Tunnel0
      ip address 192.168.254.1 255.255.255.0
      tunnel source GigabitEthernet0 / 0
      tunnel destination 20.20.20.20

    ip route 192.168.3.0 255.255.255.0 192.168.254.2 250

    Note that this setting does not encrypt packets.
    I recommend to use this way only temporarily or only when there is no other method.