Saturday, June 05, 2010

PPPoE - config example.

Thanks to Oliver P. from Cisco TAC for this one.

Yet another configuration I keep to quickly test PPPoE or particular features over PPPoE on Cisco routers.

Server
-----------
aaa new-model
!
aaa authentication ppp default local
!
virtual-template 1 pre-clone 20
!
user cisco password cisco
!
bba-group pppoe global
 virtual-template 1
!
interface faX/Y
 pppoe enable
!
interface Loopback0
 ip address 6.6.66.66 255.255.255.255
!
interface Virtual-Template1
 ip unnumbered Loopback0
 peer default ip address pool mypool
 no keepalive
 ppp authentication pap
!
ip local pool mypool 66.66.66.66 66.66.66.166
-----------
Client
-----------
bba-group pppoe global

int  faX/Y
 description PPPOE interface
 no ip address
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
!
interface Dialer1
 mtu 1454
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 no keepalive
 ppp authentication pap callin
 ppp pap sent-username cisco password 0 cisco
 ppp ipcp dns request accept
!
!
dialer-list 1 protocol ip permit
!
ip route 0.0.0.0 0.0.0.0 dialer1
-----------

L2tp over IPsec - testing configuration.

This is a configuration based on an actual customer's setup.
I keep it whenever I need to implement L2tp over IPsec on Cisco routers.

Spoke config 
--------------
l2tp-class l2tpclass1
!
pseudowire-class pwclass1
 encapsulation l2tpv2
 ip local interface FastEthernet0/0
!         
interface Virtual-PPP10
 ip address negotiated
 no peer neighbor-route
 no cdp enable
 ppp authentication pap callin
 ppp pap sent-username cisco password 0 cisco
 pseudowire 1.1.1.1 31 pw-class pwclass1
!         
dialer-list 31 protocol ip permit 

ip route 10.0.0.0 255.0.0.0 Virtual-PPP10
--------------
 
HUB config 
--------------
vpdn enable
vpdn tunnel accounting network default
vpdn session accounting network default
!
vpdn-group DailIn-L2TP/IPsec
! Default L2TP VPDN group
 accept-dialin
  protocol l2tp
  virtual-template 100
 lcp renegotiation on-mismatch
 no l2tp tunnel authentication
 l2tp tunnel timeout setup 60
 ip pmtu
!
!
username cisco privilege 15 password cisco
!
crypto keyring RING
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 no-xauth
crypto isakmp keepalive 30 5
crypto isakmp aggressive-mode disable
crypto isakmp profile L2TP
   description L2TP/IPsec HW CLients Profile
   keyring RING
   match identity address 0.0.0.0
!
!
crypto ipsec transform-set ICW esp-aes 256 esp-sha-hmac
 mode transport
crypto dynamic-map CryDynMapICW 10
 set nat demux
 set security-association lifetime kilobytes 3145728
 set transform-set ICW
 set pfs group5
 set isakmp-profile L2TP
 reverse-route
!
!
crypto map CryMapICW local-address Ethernet0/0
crypto map CryMapICW 10 ipsec-isakmp dynamic CryDynMapICW
!
!
interface Loopback100
 description L2TP Address
 ip address 10.255.0.1 255.255.255.255
!
interface Ethernet0/0
 ip address 1.1.1.1 255.255.255.0
 crypto map CryMapICW
!
interface Virtual-Template100
 ip unnumbered Loopback100
 peer default ip address pool L2TPOOL
 ppp chap hostname cisco
 ppp chap password 0 cisco
!
ip local pool L2TPOOL 5.5.5.1 5.5.5.254
------------------




Wednesday, June 02, 2010

Troubleshooting VoIP issues over ASA/PIX/FWSM appliances.

Recently I've been again put in a situation where I had to troubleshoot voice over IP issues via firewall appliances by Cisco.

Here's a brief summary of types of issues:
- No Voice (including one way voice)
- Delay
- No communication
- Features not working (MoH etc).

Now I will be the first to admit - I am voice-over-IP-agnostic, I've touched CCM or CME once or twice in my life. I'm aware that h323, sip and skinny exist.

From my perspective only two things exist in voice over IP.
- signaling
- actual payload (RTP).

So what you should know about how ASA/FWSM interacts with voice traffic.
0. Before going into voice troubleshooting check routing. In many cases a few pings can save a few hours of "missing voice" or "broken signaling"
1. First of all you most likely want to inspect your signaling traffic to/from the internet
a) Be aware that some implementations do not use default ports:
Prime example - SIP - default udp/5060 but known also to use tcp/5060 and udp/5061 (yes for signaling)
b) Be aware that if you're running voice traffic over VPN tunnel you most likely do not need to inspect traffic (everything normally should be permitted). Inspecting over VPN is waste of time (delay) and can account for some one way voice issues.
2. What does the actual inspection do:
a) Dynamically opens pinholes in your security policy to allow incoming traffic (or outgoing if relevant)
b) Pre-allocates connections and translations for traffic.
Thing to take into account here
!!!!!!
If a given IP/phone is not mentioned in signaling the traffic will NOT be allowed in. This comes over and over with music on hold from secondary CCMs. Since none of the parties actually mentions that this particular CCM will be sending MoH the traffic is neatly being dropped because of security policy.
!!!!!!!


3. ASA/FWSM inspects AND changes payload of signaling packets - and that's a good thing.
Firewalls will change internal IP address to public ones according to translation rules in place.
Be mindful when changing inspection or translation rules. "clear xlate ..." or "clear conn ..." has a big chance of recovering if something went wrong after reconfiguration either in inspection rules or NAT.

4. RSVP packets. They usually contain IP options. ASA 8.0 will drop them. Check out ip-option inspection in ASA 8.2.

5. Signaling works but voice does not go properly (dead silence and one way voice issues).
This is most likely caused by a problem with inspection or some additional policies.
Ie. Firewall should automatically open pin holes in security policy for both way RTP traffic.

Check
------
show conn detail add x.x.x.x
show x det | i x.x.x.x
------
Where x.x.x.x is the source or destination of either signaling or voice.

You should have also enabled logging on informational level and monitor logs for entries mentioning IP address of either source of destination. 

Check also those (pick ones interesting)
h323
--------
----------
SIP
-----
show sip
------
SCCP
-----
show skinny
------
I would not advise to get debugs at first - better leave those for interaction with TAC.
FYI - If it comes to TAC intervention, TAC will request "inside" and "outside" interfaces capture and debugs taken AT THE SAME TIME.

What goes without saying - !gathering packet capture helps!
If traffic is NATed and you see inside IP addresses in outside captures ... something went wrong. Maybe something similar to 4.?
Do you see packets coming into the appliance? Do you see them leaving? What has been changed.
FWSM note: Remember that inspected traffic goes straight to CPU!

Good luck.