Solved: VPN is up. Can not access LAN to LAN

pacen · ‎06-07-2018

Hello,

I need some help with my Cisco 819 LTE router.
The internet connection works great(configured over Cellular/lte).

The VPN from our HQ is up on both sides but I can not access the network from LAN to LAN in any direction - 192.168.80.0/24(Cisco 819) <==> 192.168.10.0/24(HQ).

cisco/remote location - Cisco 819 WAN: XXX.XXX.XXX.XXX, LAN 192.168.80.0/24
Main HQ - WAN: YYY.YYY.YYY.YYY, LAN 192.168.10.0/24

Any help would be geatly apreciated

Best regards,

Building configuration...

  
  
Current configuration : 4545 bytes
!
! Last configuration change at 09:47:57 UTC Thu Jun 7 2018
!
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Potrceva
!
boot-start-marker
boot-end-marker
!
!
no logging console
enable secret 5 $1$-dcK$VGdflklRAg2hhxCiokneA/
enable password somepass
!
no aaa new-model
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!


!
ip dhcp excluded-address 192.168.80.1 192.168.80.30
!
ip dhcp pool vlan1pool
 network 192.168.80.0 255.255.255.0
 default-router 192.168.80.1 
 dns-server 8.8.8.8 
!
!
!
ip domain name potrceva.local
ip cef
no ipv6 cef
!
!
flow record nbar-appmon
 match ipv4 source address
 match ipv4 destination address
 match application name
 collect interface output
 collect counter bytes
 collect counter packets
 collect timestamp absolute first
 collect timestamp absolute last
!
!
flow monitor application-mon
 cache timeout active 60
 record nbar-appmon
!
!
!
!
!
multilink bundle-name authenticated
!
!
chat-script lte "" "AT!CALL" TIMEOUT 20 "OK"
!
!
!
!
!
license udi pid C819G-4G-GA-K9 sn FCZ221111EE
!
!
object-group network local_cws_net 
!
object-group network local_lan_subnets 
 any
!
object-group network vpn_remote_subnets 
 any
!
username admin privilege 15 secret 5 $1$2ikmndz6CQoo/kldjsU2/ld8XIdQ.
!
redundancy
!
!
!
!
!
controller Cellular 0
 lte modem link-recovery rssi onset-threshold -110
 lte modem link-recovery monitor-timer 20
 lte modem link-recovery wait-timer 10
 lte modem link-recovery debounce-count 6
!
zone security LAN
zone security WAN
zone security VPN
zone security DMZ
! 
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 5
crypto isakmp key SuperPSK address YYY.YYY.YYY.YYY
!
!
crypto ipsec transform-set TS esp-3des esp-md5-hmac 
 mode tunnel
!
!
!
crypto map CMAP 10 ipsec-isakmp 
 set peer YYY.YYY.YYY.YYY
 set transform-set TS 
 match address VPN-TRAFFIC
!
!
!
!
!
!
interface Cellular0
 ip address negotiated
 ip nat outside
 ip virtual-reassembly in
 encapsulation slip
 dialer in-band
 dialer string lte
 dialer-group 1
 crypto map CMAP
!
interface Cellular1
 no ip address
 encapsulation slip
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface GigabitEthernet0
 ip address dhcp
 ip nat outside
 ip virtual-reassembly in
 shutdown
 duplex auto
 speed auto
!
interface Serial0
 no ip address
 shutdown
 clock rate 2000000
!
interface Vlan1
 ip address 192.168.80.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
ip forward-protocol nd
ip http server
no ip http secure-server
!
!
ip nat inside source list NAT interface Cellular0 overload
ip route 0.0.0.0 0.0.0.0 Cellular0
ip ssh rsa keypair-name SSH
ip ssh version 2
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
!
ip access-list extended NAT
 permit ip 192.168.80.0 0.0.0.255 any
ip access-list extended VPN-TRAFFIC
 permit ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
 permit ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
ip access-list extended nat-list
 permit ip object-group local_lan_subnets any
!
dialer-list 1 protocol ip permit
ipv6 ioam timestamp
!
snmp-server community public RO
access-list 1 permit 192.168.80.0 0.0.0.255
access-list 100 permit tcp host YYY.YYY.YYY.YYY host XXX.XXX.XXX.XXX eq 22
access-list 100 permit tcp 192.168.80.0 0.0.0.255 host 192.168.80.1 eq 22
access-list 100 deny   tcp any host XXX.XXX.XXX.XXX eq 22
access-list 100 permit ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 100 permit ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
access-list 100 deny   tcp any host XXX.XXX.XXX.XXX eq ftp
access-list 100 permit tcp 192.168.80.0 0.0.0.255 host 192.168.80.1 eq www
access-list 100 deny   tcp any host XXX.XXX.XXX.XXX eq www
access-list 100 deny   tcp any host XXX.XXX.XXX.XXX
!
control-plane
!
!
!
mgcp behavior rsip-range tgcp-only
mgcp behavior comedia-role none
mgcp behavior comedia-check-media-src disable
mgcp behavior comedia-sdp-force disable
!
mgcp profile default
!
!
!
!
!
!
 vstack
!
line con 0
 no modem enable
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 stopbits 1
line 3
 script dialer lte
 no exec
 rxspeed 100000000
 txspeed 50000000
line 8
 no exec
 rxspeed 100000000
 txspeed 50000000
line vty 0 4
 exec-timeout 0 0
 login local
 transport input ssh
!
scheduler allocate 20000 1000
!
!
!
!
!
!
end

Georg Pauwen · ‎06-27-2018

Hello,

you are not denying the traffic, you just prevent LAN to LAN traffic from being NATted and subsequently routed out to the Internet.

As Richard mentioned, the access list needs to look like this:

Extended IP access list NAT
10 deny ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
20 deny ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255

30 permit ip 192.168.80.0 0.0.0.255 any (616745 matches)

View solution in original post

Georg Pauwen · ‎06-14-2018

Hello,

change your NAT access list as below:

ip access-list extended NAT
deny ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
deny ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
permit ip 192.168.80.0 0.0.0.255 any

pacen · ‎06-26-2018

Hello. Sorry for the late replay. I was on vacation :)

Hmmm I added the lines that you suggested but no difference. Here is my access-list:

    10 permit 192.168.80.0, wildcard bits 0.0.0.255
Extended IP access list 100
    10 permit tcp host YYY.YYY.YYY.YYY host XXX.XXX.XXX.XXX eq 22
    20 permit tcp 192.168.80.0 0.0.0.255 host 192.168.80.1 eq 22
    30 deny tcp any host XXX.XXX.XXX.XXX eq 22
    40 permit ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
    50 permit ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
    60 deny tcp any host XXX.XXX.XXX.XXX eq ftp
    70 permit tcp 192.168.80.0 0.0.0.255 host 192.168.80.1 eq www
    80 deny tcp any host XXX.XXX.XXX.XXX eq www
    90 deny tcp any host XXX.XXX.XXX.XXX eq 443
Extended IP access list NAT
    10 permit ip 192.168.80.0 0.0.0.255 any (616745 matches)
    20 deny ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
    30 deny ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
Extended IP access list VPN-TRAFFIC
    10 permit ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
    20 permit ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255
Extended IP access list nat-list
    10 permit ip object-group local_lan_subnets any

What I have discovered is that there is perhaps a route problem. :/
I do not think that it could be anything other

Potrceva#show run | inc ip route
ip route 0.0.0.0 0.0.0.0 Cellular0

Potrceva#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, Cellular0
      XXX.XXX.0.0/32 is subnetted, 1 subnets
C        XXX.XXX.XXX.XXX is directly connected, Cellular0
      192.168.80.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.80.0/24 is directly connected, Vlan1
L        192.168.80.1/32 is directly connected, Vlan1
Potrceva#

Best regards

Richard Burts · ‎06-26-2018

I am not clear what is going on here. You originally used ACL for address translation nat-list. Then a suggestion for change was made using ACL NAT. In your most recent post both ACL are present. But there is no indication which one is actually used in your address translation configuration.

There is a problem in the way that you have implemented the suggestion using ACL NAT. The suggestion had two deny statements followed by a single permit statement. What you have implemented is the single permit followed by the deny statements. The order of statements in the ACL is important. And what is happening is that the traffic that you are attempting to deny with the last two statements has already been permitted by your first statement. So change your ACL so that it does match the order given in the suggestion. And verify that this is the ACL actually used by your address translation configuration.

What in your output of the routing table looks like a problem to you? It all looks ok to me.

HTH

Rick

HTH

Rick

pacen · ‎06-26-2018

Hello. Thank you for the reply.

I understand the that the order is important.
What I realy do not understand is why should I deny this.
I actually want that the traffic gets troug from LAN to LAN, not to deny it.
The problem is that the traffic does not flow between LANs

Best regards

Georg Pauwen · ‎06-27-2018

Hello,

you are not denying the traffic, you just prevent LAN to LAN traffic from being NATted and subsequently routed out to the Internet.

As Richard mentioned, the access list needs to look like this:

Extended IP access list NAT
10 deny ip 192.168.80.0 0.0.0.255 192.168.10.0 0.0.0.255
20 deny ip 192.168.10.0 0.0.0.255 192.168.80.0 0.0.0.255

30 permit ip 192.168.80.0 0.0.0.255 any (616745 matches)

Richard Burts · ‎06-27-2018

The concern expressed by the original poster about not wanting to deny the traffic represents a misunderstanding that is fairly common. We tend to think of using access lists to permit or deny the transmission of packets. But that is not their only use. As Georg has explained in this case the ACL is used to control the address translation. The traffic that is denied in this ACL can still be transmitted, it just will not be translated.

The issue here is that the remote end expects to see traffic over the VPN with source address of 192.168.80.x. If the traffic over the VPN is not translated then the source address will be as expected 192.168.80.x. But with the nat ACL permitting the traffic then the VPN traffic will be translated. And when it reaches the other end of the VPN the source address will be the address of the cellular interface. That is the reason why the VPN has not been passing traffic - the remote peer is not seeing the source address that it expects to see.

HTH

Rick

HTH

Rick

pacen · ‎06-29-2018

It actually works. You guys are the best!
Thank you for your help and learning info.

Best regards to you all :)