A Few Services Cannot Be Visited if USG5310 Dial-Up by L2tp OVER IPSEC

Publication Date:  2012-09-14 Views:  216 Downloads:  0
Issue Description
Topology
Public network-- USG5310—cisco switch—internal network PC

Public network clients visit internal network service by L2TP OVER IPSEC dial-up ,most of computers can be visited, but a few services cannot be visited.
Configuration as follows
[USG5310]dis cu
11:36:56  2012/02/22
#
sysname USG5310
#
l2tp enable
l2tp domain suffix-separator @
#
ike local-name usg5310
#
firewall packet-filter default permit interzone local trust direction inbound
firewall packet-filter default permit interzone local trust direction outbound
firewall packet-filter default permit interzone local untrust direction inbound
firewall packet-filter default permit interzone local untrust direction outbound
firewall packet-filter default permit interzone trust untrust direction inbound
firewall packet-filter default permit interzone trust untrust direction outbound

nat address-group 1 116.236.132.138 116.236.132.139

#
firewall session link-state check

acl number 3003
description (eq 1701)
rule 10 permit udp source-port eq 1701
rule 20 permit udp destination-port eq 1701
#
description vpncar(bad)
rule 0 permit ip source 10.90.9.0 0.0.0.255
rule 5 permit ip destination 10.90.9.0 0.0.0.255
#
#
ike proposal 10
authentication-algorithm md5
#
ike peer lac
exchange-mode aggressive              
pre-shared-key yofcsh@3031
ike-proposal 10
undo version 2
local-id-type name
remote-name client
nat traversal
#
ipsec proposal tran1
#
ipsec policy-template tmap 1
speed-limit inbound 500
security acl 3003
ike-peer lac
proposal tran1
#
ipsec policy map 1 isakmp template tmap

interface Virtual-Template1
ppp authentication-mode chap
ip address 10.90.9.1 255.255.255.0
remote address pool 1
#
interface GigabitEthernet0/0/0
ip address 192.168.0.1 255.255.255.0
#
interface GigabitEthernet0/0/1
speed 100
ip address 116.236.132.142 255.255.255.248
ipsec policy map
#
interface GigabitEthernet0/0/2
ip address 192.168.88.8 255.255.255.0 
#
interface GigabitEthernet0/0/3
ip address 10.90.1.254 255.255.255.0
qos apply policy s_w_o outbound

firewall zone local
set priority 100

firewall zone trust
set priority 85
add interface GigabitEthernet0/0/0
add interface GigabitEthernet0/0/3
add interface Virtual-Template1

firewall zone untrust
set priority 5
add interface GigabitEthernet0/0/1
#
firewall zone dmz
set priority 50
add interface GigabitEthernet0/0/2
#
firewall interzone trust untrust
detect qq
detect msn
#
#
l2tp-group 1
undo tunnel authentication
allow l2tp virtual-template 1         
tunnel name lns
#
aaa
local-user sales password simple yofcsh@3030
local-user sales service-type ppp
ip pool 1 10.90.9.100 10.90.9.200
                                     


ip route-static 0.0.0.0 0.0.0.0 116.236.132.137
ip route-static 10.90.2.0 255.255.255.0 10.90.1.1
ip route-static 10.90.3.0 255.255.255.0 10.90.1.1

                                 
policy interzone trust untrust outbound
policy 0
  action permit
  policy source 10.90.1.0 0.0.0.255

policy 1
  action permit
  policy source range 10.90.2.99 10.90.2.253

policy 2                              
  action permit
  policy source 10.90.3.0 0.0.0.255

nat-policy interzone trust untrust outbound
policy 0
  action no-nat
  policy source 10.90.1.0 mask 24
  policy destination 10.90.9.0 mask 24

policy 1
  action source-nat
  policy source 10.90.0.0 0.0.255.255
  address-group 1                      

Alarm Information
NULL 
Handling Process
Amend the address mark to 255.255.255.0 same with Virtual-Template1 port. Other services that cannot be visited face the same problem, solve the problem by amending the address mark.
[USG5310]ping -a  10.90.9.1 10.90.1.10
11:38:16  2012/02/22
  PING 10.90.1.10: 56  data bytes, press CTRL_C to break
    Reply from 10.90.1.10: bytes=56 Sequence=1 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=2 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=3 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=4 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=5 ttl=127 time=1 ms

Root Cause
Check L2TP OVER IPSEC configuration and find no problem
Test for service IP 10.90.1.10 on equipment
[USG5310]dis ip in b
11:37:56  2012/02/22
*down: administratively down
(s): spoofing
Interface                   IP Address      Physical Protocol Description
GigabitEthernet0/0/0        192.168.0.1     down     down     Huawei Storage &
GigabitEthernet0/0/1        116.236.132.142 up       up       Huawei Storage &
GigabitEthernet0/0/2        192.168.88.8    down     down     Huawei Storage &
GigabitEthernet0/0/3        10.90.1.254     up       up       Huawei Storage &
Virtual-Template1           10.90.9.1       up       up(s)    Huawei Storage &
[USG5310]ping  10.90.1.10
11:38:16  2012/02/22
  PING 10.90.1.10: 56  data bytes, press CTRL_C to break
    Reply from 10.90.1.10: bytes=56 Sequence=1 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=2 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=3 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=4 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=5 ttl=127 time=1 ms

  --- 10.90.1.10 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
round-trip min/avg/max = 1/1/1 ms

It can be ping directly on the equipment

[USG5310]ping -a 116.236.132.142 10.90.1.10
11:39:23  2012/02/22
  PING 10.90.1.10: 56  data bytes, press CTRL_C to break
    Reply from 10.90.1.10: bytes=56 Sequence=1 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=2 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=3 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=4 ttl=127 time=1 ms
    Reply from 10.90.1.10: bytes=56 Sequence=5 ttl=127 time=1 ms

  --- 10.90.1.10 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
round-trip min/avg/max = 1/1/1 ms

Ip address with public network also can be ping

[USG5310]ping -a  10.90.9.1 10.90.1.10
11:38:46  2012/02/22
  PING 10.90.1.198: 56  data bytes, press CTRL_C to break
    Request time out
    Request time out
    Request time out
    Request time out
    Request time out

  --- 10.90.1.10 ping statistics ---
    5 packet(s) transmitted
    0 packet(s) received
100.00% packet loss

Ip address with Virtual-Template1 cannot be ping

look up session information

[USG5310]dis firewall session table verbose destination inside 10.90.1.10
12:31:05  2012/02/24
Current Total Sessions : 2
  icmp  VPN:public --> public
  Zone: local--> trust  TTL: 00:00:20  Left: 00:00:16
  Interface: GigabitEthernet0/0/3  NextHop: 10.90.1.236  MAC: 00-00-00-00-00-00
  <--packets:0 bytes:0   -->packets:5 bytes:420
  10.90.9.1:44058-->10.90.1.10:2048

It found that there are out packets but no return packets, it means the firewall did not receive packets service answer.
The problem maybe in the service configuration

It can ping the service with 10.90.1.10, and the ip address mark is (10.90.1.10 255.255.0.0), when we ping with public network address, it can be ping because they are the same network segment. When we ping with Virtual-Template1 address 10.90.9.1, because the service 10.90.1.10 is 16 address mark, in the same network segment, so it pass the 2 layer forwarding, it will not send the packets to the gateway.
Suggestions
Address mark failure result in visit disable because of the client negligence. Check the address mark failure if the equipment configuration is normal. 

END