Howto: Create a VPN site-to-site with GNS3

I have definitely abandoned Verdana font since each time it changes after publishing posts :) )

In this article I will show how to create a VPN site-to-site in GNS3.

First of all we have to create the topology, so create a new project and drag elements to reproduce this:

Let's take a look to what we have starting from bottom left clockwise:

• CE1 is our Branch Office router that will connect to the Main Office
• PE1 is our Provider Edge router that connects the Branch Office to the Internet
• PE2 is our Provider Edge router that connects the Main Office to the Internet
• CE2 is our Main Office router that connects the headquarter to the Internet
• C1 is a cloud connected to a Loopback interface configured with IP address 192.168.233.101 (this element is optional, you can substitute it with an Ethernet Switch)

Now let's configure all of the router with basic configuration and assign IP addresses as follows:

#CE1

hostname CE1


line con 0


logging synchronous


exec-timeout 0


!


interface FastEthernet0/0


ip address 192.168.233.254 255.255.255.0


no shutdown


!


interface Serial1/0


ip address 192.168.30.1 255.255.255.252


no shutdown

#PE1

hostname PE1


line con 0


logging synchronous


exec-timeout 0


!


interface Serial1/0


ip address 192.168.30.5 255.255.255.252


no shutdown


!


interface Serial1/1


ip address 192.168.30.2 255.255.255.252


no shutdown

#PE2

hostname PE2


line con 0


logging synchronous


exec-timeout 0


!


interface Serial1/0


ip address 192.168.30.6 255.255.255.252


no shutdown


!


interface Serial1/1


ip address 192.168.30.10 255.255.255.252


no shutdown



#CE2

hostname CE2


line con 0


logging synchronous


exec-timeout 0


!


interface FastEthernet0/0


ip address 192.168.210.254 255.255.255.0


!


interface Serial1/0


ip address 192.168.30.9 255.255.255.252


no shutdown

To ensure that the "public network" has fully reachability, we will configure eigrp on network 192.168.30.0 and disable auto-summarization since our network is subnetted:

# CE1, CE2, PE1, PE2

router eigrp 1


network 192.168.30.0


no auto-summary

After this step you should be able to ping 192.168.30.9 from CE1.

Now we are going to configure an IPSec VPN site-to-site, so we will need:

1. crypto isakmp policy
   
   
   are numbered policies that specifies parameters for IKE Phase 1 connection and at least one policy on the initiator must match with the isakmp policies configured on the responder
   
   
   multiple policies can be configured, they will be selected starting from lower numbers, so is heavily recommended to assign those number to stronger policies
2. crypto ipsec transport-set
   
   
   the transport sets define IPSec parameters for SAs established in IKE Phase 2. On a single transform set can be specified up to three protocol/algorithm specifications
3. interesting traffic ACL
   
   
   an ACL specifying "interesting traffic", i.e. the traffic that will be carried over IPSec connection
4. crypto map
   
   
   is an object that maps together ACL, transform set and the peer IP address
5. create a static route
   
   
   a static route needs to be created to forward the traffic for the remote network to the peer
6. apply the crypto map to the outgoing interface
   
   
   the crypto map must be applied to the interface the traffic to remote network will go out from

1. crypto isakmp policy

Our IPSec peers will be CE1 and CE2, so on both ends we will create isakmp policies. Remember that at least one of them must match on the other peer unless the connection will not bring up.

Just to make it easy, we will configure the same policies on both. Our policy with priority 10 will user 3-DES encryption and MD5 hashing and a pre-shared key authentication, while a weaker isakmp policy with priority 20 will use a simple SHA-1 hashing:

#CE1 and CE2

crypto isakmp policy 10


encryption 3des


hash md5


authentication pre-share


!


crypto isakmp policy 20


hash sha


!

Then we must assign a pre-shared key to the peer. Please note that pre-shared password assignment is not on specific policies, but is on a per-peer basis. That means that when IKE Phase 1 is initialized, if an isakmp policy matches and it contains "authentication pre-share", then the remote peer will have to supply the password matching its IP address.

We configure CE1 and CE2 so that they must supply the password "mypassword" to confirm their identity

#CE1 and CE2

crypto isakmp key mypassword address 192.168.30.9

2. crypto ipsec transform-set

The second step is to configure our transport sets. Since each command allows to specify up to three protocol/algorithm combination, we will create a set that will use ESP 3-DES encryption and AH with SHA-1 hashing in transport mode

#CE1 and #CE2

crypto ipsec transform-set set-10 ah-sha-hmac esp-3des


mode transport


!


crypto ipsec security-association lifetime seconds 120



In the last command we have defined the lifetime for each single SA too

3. interesting traffic ACL

Now we must specify the traffic that we are going to encapsulate through the IPSec secure channel.

On CE1 we will protect all the traffic going out from 192.168.233.0 network directed to 192.168.210.0 network through the ISP's network, while CE2 will have a mirrored ACL

#CE1

access-list 110 permit ip 192.168.233.0 0.0.0.255 192.168.210.0 0.0.0.255



#CE2

access-list 110 permit ip 192.168.210.0 0.0.0.255 192.168.233.0 0.0.0.255



4. crypto map

In the previous steps we have defined general parameters for IKE Phase 1 and IKE Phase 2 and the traffic that we want to protect. Now we must configure a mapping between the parameters, the traffic and the peer host. Basically all of the configuration done before, exception done for the ACL, will be shared by any VPN connection the router will initiate or respond to.

On CE1 we are going to create a crypto map named remote-to-main, we will give it a priority value 10 and specify that it will use isakmp policies. In the crypto map contest then we will specify remote peer ip address, the transform set that will be used for IKE Phase 2 and the ACL that specifies the interesting traffic

#CE1

crypto map remote-to-main 10 ipsec-isakmp


set peer 192.168.30.9


set transform-set set-10


match address 110

On CE2 we will create a crypto map named main-to-remote with the same parameters changing the ip address of the remote peer

#CE2

crypto map main-to-remote 10 ipsec-isakmp


set peer 192.168.30.1


set transform-set set-10


match address 110

5. create a static route

Since remote networks are not announced by EIGRP, CE1 and CE2 cannot reach their respective private networks. To allow this we need to create a static route as follows:

#CE1

ip route 192.168.210.0 255.255.255.0 192.168.30.9



#CE2

ip route 192.168.233.0 255.255.255.0 192.168.30.1

6. apply the crypto map to the outgoing interface

in this last step we still need to apply the crypto map on the outgoing interface for destination network. A trick is to apply the crypto map on the interface facing the link used to reach the remote network.

For CE1 the outgoing interface for network 192.168.210.0 is s1/0 and for CE2 the outgoing interface for network 192.168.233.0 is s1/0:

#CE1

interface s1/0


crypto map remote-to-main#CE2

#CE2

interface s1/0


crypto map main-to-remote

Testing the configuration

Now that the config part has finished, we must test if everything is working as expected.

First we can ping from CE1 the remote network:

#ping 192.168.210.254

This WILL NOT WORK! Guess why? Because the ACL we specified identifies the traffic to be protected. As for default settings, your ping to 192.168.210.0 network will use outgoing interface ip address, that is 192.168.30.1. This traffic will not match ACL, so no IPSec channel is established.

Now, try with

#ping 192.168.210.254 source fa0/0

and if you followed all of the previous steps you will finally get an answer.

If you want you can use even your PC through loopback adapter, but remember that you will have to create a static route for network 192.168.210.0/24 to use 192.168.233.254 as gateway.

Now from CE1 issue the command

show crypto ipsec sa

you should have an output like this (interesting things are in red):

interface: Serial1/0


Crypto map tag: remote-to-main, local addr 192.168.30.1

protected vrf: (none)


local ident (addr/mask/prot/port): (192.168.233.0/255.255.255.0/0/0)


remote ident (addr/mask/prot/port): (192.168.210.0/255.255.255.0/0/0)


current_peer 192.168.30.9 port 500


PERMIT, flags={origin_is_acl,}


#pkts encaps: 13, #pkts encrypt: 13, #pkts digest: 13


#pkts decaps: 13, #pkts decrypt: 13, #pkts verify: 13


#pkts compressed: 0, #pkts decompressed: 0


#pkts not compressed: 0, #pkts compr. failed: 0


#pkts not decompressed: 0, #pkts decompress failed: 0


#send errors 17, #recv errors 0

local crypto endpt.: 192.168.30.1, remote crypto endpt.: 192.168.30.9


path mtu 1500, ip mtu 1500


current outbound spi: 0x71ADC14D(1907212621)

inbound esp sas:


spi: 0x813BA0FB(2168168699)


transform: esp-3des ,


in use settings ={Tunnel, }


conn id: 2002, flow_id: SW:2, crypto map: remote-to-main


sa timing: remaining key lifetime (k/sec): (4453225/44)


IV size: 8 bytes


replay detection support: Y


Status: ACTIVE

inbound ah sas:


spi: 0xECD85DFD(3973602813)


transform: ah-sha-hmac ,


in use settings ={Tunnel, }


conn id: 2002, flow_id: SW:2, crypto map: remote-to-main


sa timing: remaining key lifetime (k/sec): (4453225/34)


replay detection support: Y


Status: ACTIVE

outbound esp sas:


spi: 0x71ADC14D(1907212621)


transform: esp-3des ,


in use settings ={Tunnel, }


conn id: 2001, flow_id: SW:1, crypto map: remote-to-main


sa timing: remaining key lifetime (k/sec): (4453225/34)


IV size: 8 bytes


replay detection support: Y


Status: ACTIVE

outbound ah sas:


spi: 0x90972444(2425824324)


transform: ah-sha-hmac ,


in use settings ={Tunnel, }


conn id: 2001, flow_id: SW:1, crypto map: remote-to-main


sa timing: remaining key lifetime (k/sec): (4453225/34)


replay detection support: Y

IPSec Fundamentals - Part II

In the first part of IPSec Fundamentals we had a general view of what IPSec can do and how.

In this part we will go deeper inside this technology to discover how it works and how is currently used to protect traffic over the Internet

IPSec features Data Origin Authentication provided by IKE depends upon mutual authentication of both ends of secure communication channel, this authentication can be done using:

• Pre-configured username and password on endpoints


• OTP (One-time password) such as PIN o single-time transactions


• Biometric authentication


• Pre-shared Keys


• Digital certificates

IPSec Data integrity and anti-replay provided by AH and ESP depend upon hashing. Following methods are available:

• SHA-1 (weaker)


• MD5

IPSec Data Confidentiality provided by ESP depend upon encryption algorithms:

• DES


• 3-DES


• AES

Now we have all the elements that compose IPSec architecture, we have protocols, authentication methods, hashing and encrypting algorithms and two different modes to use them. In the next section we will see how an IPSec connection is established and how secure communications are built over this connection.

The whole IPSec features use a secure, bi-directional or mono-directional channels named SAs (Security Association) that are agreement of IPSec parameters between two peers

IKE (Internet Key Exchange) is a protocol that allows two hosts to exchange a private key (like a password) and IPSec parameters in a secure way over an unsecure connection. IKE can use two different existing protocol to complete this task:

• ISAKMP (Internet Secure Association and Key Management Protocol) that provides both SA creation/deletion, key exchange and peers authentication


• Oakley that uses Diffie-Hellman algorithm to exchange keys

The need to have a secure key exchange capability is due to the fact that passwords or pre-shared keys are often manually configured, so you actually need a way to exchange and/or update passwords to other peers.

IKE job is divided into two main phases:

• IKE Phase 1 (mandatory)
  
  
  in this phase the two peers negotiate common IPSec connection parameters and peer authentication takes place.
  
  
  If both peers agree on IPSec parameters and succesfully authenticate each other, a bi-directional SA is established
  
  
  IKE Phase 1 can be initiated in two modes:


• 
  
  
  
  • IKE Phase 1 Main Mode
  
  
  • IKE Phase 1 Aggressive Mode
  
  
  
  


• IKE Phase 1.5 (optional)
  
  
  in phase 1 both peers authenticate each other, but if user behind the device requesting the connection must be authenticated too, it can be done using Xauth to request login to end user and authenticate him before granting IPSec connection


• IKE Phase 2 (mandatory)
  
  
  in this phase mono-directional SAs are created between IPSec endpoints using IKE Quick Mode. The new SAs uses different keys for each SA

So we have seen how IKE is the protocol that allows two IPSec peers to establish a connection, the two main phases, IKE Phase 1 and IKE Phase 2 and the three different IKE Modes: IKE Quick Mode and IKE Aggressive Mode for Phase 1 and IKE Quick Mode for Phase 2.

It may sound a little tricky, but just think about it: you have two peers that need to make a secure connection *before* authenticating each other, now you first need a protocol to provide you a way to establish this connection. This is IKE. Since with IPSec you can use different protocols (AH and ESP), different modes (tunnel or transport), different algorithms for hashing and encryption, you need this protocol to negotiate these parameters before you can use this connection.

In second stage, you need a *secure* channel, so you must authenticate your peer and it will authenticate you too. Additionally, you may want to change your passwords or pre-shared keys for security purpose or because they were compromised, so you will need a way to exchange or update keys to make your solution scalable and manageable.

Let's take a look to the connection process: you initiate a connection to a remote router, so we are in IKE Phase 1 where we can have IKE Main Mode or IKE Aggressive Mode. First of all we must agree about IPSec connection parameters, then we must exchange our keys to provide a secure channel for authentication process. Last we authenticate each other and establish a bi-directional SA.

Once we have a secure channel, things are less complicated, so IKE Phase 2 can use IKE Quick Mode to establish new SAs (uni-directional) that will be used for data encryption and this can be done using our existing secure channel, over which we will exchange parameters and keys for new SAs

Some details on IKE Modes

IKE Main Mode (6 packets):

• The initiator sends parameters set proposals, the responders select the appropriate one


• Diffie-Hellman is used to exchange public keys between peers


• ISAKMP is used to authenticate the session for both peers


• The bi-directional SA is established

IKE Aggressive Mode (3 packets):

• The initiator sends parameters, policies and Diffie-Hellman public keys


• The responder authenticates the packet, then sends parameters proposal, keys and authentication back


• The initiator authenticates the packet


• The bi-directional SA is established

IKE Quick Mode

• Negotiates SA parameters


• Key exchange for specific SA

Control and management of SAs is also provided by IKE:

• DPD (Dead Peer Detection)
  
  
  a keepalive is sent (10s by default) to detect if remote peer is responding


• NAT Transversal
  
  
  during IKE Phase 1 if NAT is detected through connection, an additional UDP header is added to support this configuration


• Mode configuration
  
  
  can be used to send to the initiator client all of the configuration settings for connection (f.e. Cisco Easy VPN)


• XAuth

IPSec Fundamentals - Part I

IPSec (IP Security) is a set of features used to protect traffic on IP networks generally over an Internet connection.

Since IPSec connections are built over an existing IP infrastructure, you can think of it as a common transport protocol (Layer 4) such as TCP or UDP, but with much more security features of course. Anyway the point here is that the IPSec headers are always transported by Layer 3 connections through the network (if you think about it you will easily understand that if you want to make a secure connection between two hosts you have to be able to establish an IP connection first)


IPSec we said is actually a set of features and not a protocol, so let's take a look to the offered features:

• Data integrity (data has not been modified)


• Data origin authentication (sender and receiver are verified)


• Anti-replay (data cannot be replicated over the network)


• Data confidentiality (data is encrypted)

Each of these features can be implemented using open standard protocols to assure interoperability between different vendors. These protocols are:

• IKE (Internet Key Exchange)


• AH (Authentication Header)


• ESP (Encapsulating Security Payload)

IKE is used to negotiate parameters and to establish the connection between two hosts, while AH and ESP are used over that connection to provide some or all of the features listed above

Now we have an overview of IPSec, we know that is similar to a Layer4 transport protocol and is used to establish secure connections between two hosts over an unprotected network, it uses different protocol to fit security requirements, each protocol has its own function and limitations

IPSec connection can be made in two different modes:

• Transport Mode


• Tunnel Mode

Before discussing the differences between them, remember that IPSec headers are always encapsulated into Layer 3 headers, so anyone who would see our packets travelling over the unsecured network will always be able to see the content of this Layer 3 header (and it's required otherwise no IP connectivity would be possible).

To better explain the difference think of two hosts with public IP addresses connected to the Internet by two routers/firewalls. The hosts can communicate between them but we need to make these communication secure, so IPSec is the answer. Please consider that in this post I will not take in consideration the IPSec services available on servers like Windows Server 2003, 2008 or Unix-like. Each of these operating systems can support the creation of IPSec connections directly but it's not our scenario. We are going to protect traffic using router's capabilities only.

In Transport Mode, we tell the routers to protect all of IP traffic between the two hosts with IPSec starting from Layer 4, so all of the IP packets to or from these destinations would be modified as follows:

The Layer 3 IP Header is not modified and it contains the target host's IP


The Layer 4 (TCP or UDP) Header and the data are processed by the chosen protocol (AH or ESP)


IPSec encapsulates into a new AH or ESP header the processed data


The outgoing packet will contain the original Layer 3 header, the AH or ESP Header, the original Layer 4 header and the data


In Tunnel Mode, we tell the routers to protect all of IP traffic between the two hosts with IPSec starting from Layer 3, so IP packets between them will be modified as follows:


The Layer 3 Header containing the target host's IP address, the Layer 4 (TCP or UDP) Header and the data are processed by the chosen protocol (AH or ESP) IPSec encapsulates into a new AH or ESP header the processed data IPSec creates a new Layer 3 Header containing the remote router's IP address


The outgoing packet will contain the new Layer 3 header, the AH or ESP header, the original Layer 3 header, the original Layer 4 header and the data




As you can easily see Tunnel Mode not only provides protection for Layer 4 communications, but it protects Layer 3 headers too with the main advantage to hide actual IP addresses inside the protected traffic leaving routers' IP addresses exposed to potential unauthorized intruders

Still consider that not all of the IPSec protected traffic is encrypted, encryption is just one of the features of IPSec (even if important). Since any of the capabilities offered by IPSec require overhead and router's workload, encrypting all of the traffic is usually not a good idea.

Howto: using simple MPLS traffic engineering capabilities with GNS3 and Dynamips

This article covers the main steps to create an MPLS frame mode network and to configure traffic-engineering MPLS features to select specific paths over the network with dedicated bandwidth.

Many elements here are taken from ibarrere's blog on networking-forum.com


In brief, the network will run standard OSPF routing while path selection and bandwidth is delegated to MPLS and RSVP protocols.






Please note that this article does not cover MPLS-VPN capabilities, maybe in a few day I'll take the time to write it down too.






1) Create a new project with GNS3 and place routers and connections as from the topology image, then assign IP addresses to ethernet and loopback interfaces

2) Enable OSPF on each router that connects to the "backbone" (R0, R1, R2, R3) and verify that adjacencies are being established correctly


(config)#router ospf 1
(config-router)#network 172.16.0.0 0.0.255.255 area 0

 

3) Enable MPLS and MPLS traffic-engineering on each router that connects to the backbone (R0, R1, R2, R3)


(config)#mpls ip
(config)#mpls traffic-eng tunnels




4) Configure OSPF to transport MPLS information


(config-router)#mpls ldp autoconfig area 0
(config-router)#mpls traffic-eng router-id Loopback0
(config-router)#mpls traffic-eng area 0


 5) On R0 create a tunnel interface that will connect to R3


(config)#interface Tunnel2

(config-if)#ip unnumbered Loopback0

(config-if)#tunnel destination 172.16.255.13

(config-if)#tunnel mode mpls traffic-eng

(config-if)#tunnel mpls traffic-eng autoroute announce

(config-if)#tunnel mpls traffic-eng priority 2 2

(config-if)#tunnel mpls traffic-eng bandwidth 158

(config-if)#tunnel mpls traffic-eng path-option 1 explicit name BOTTOM

(config-if)#no routing dynamic

 

6) Create on R0 a path that will specify step-by-step every router that will be traversed by the tunnel.


In this example we will suppose that we want to use MPLS traffic-engineering to force all traffic


between R4 and R5 to be forwarded through R2 path only. We well call this path BOTTOM:


(config)#ip explicit-path name BOTTOM enable

(cfg-ip-expl-path)#next-address 172.16.1.2

(cfg-ip-expl-path)#next-address 172.16.3.2





7) Now since MPLS traffic engineering tunnels are UNIdirectional, we will need to configure R3 with a mirrored R0 configuration, first of all we create a tunnel interface changing the destination IP:


(config)#interface Tunnel2

(config-if)#ip unnumbered Loopback0

(config-if)#tunnel destination 172.16.255.10

(config-if)#tunnel mode mpls traffic-eng

(config-if)#tunnel mpls traffic-eng autoroute announce

(config-if)#tunnel mpls traffic-eng priority 2 2

(config-if)#tunnel mpls traffic-eng bandwidth 158

(config-if)#tunnel mpls traffic-eng path-option 1 explicit name BOTTOM

(config-if)#no routing dynamic

 

8) Then we create on R3 a mirrored explicit-path too:


(config)#ip explicit-path name BOTTOM enable

(cfg-ip-expl-path)#next-address 172.16.3.1

(cfg-ip-expl-path)#next-address 172.16.1.1


Please note that this is the simplest configuration choice, but any other path to R0 would be

suitable as well

 

9) Now we need to enable MPLS traffic-enginering tunnels on all the interfaces except for those on subnets 10.x.x.x, that is: R0 (f0/0 and f0/1), R2 (all), R1 (all), R3 (f0/0 and f0/1)


(config-if)#mpls ip

(config-if)#mpls traffic-eng tunnels

(config-if)#ip rsvp bandwidth


10) We need to add the CE facing interfacing of R4 and R5 to OSPF to be ridistributed with IGP, on R0 fa1/0 and R3 fa1/0 interfaces we add:


(config-if)#ip ospf 1 area 0




11) The last thing to do is to add a static route to R4 and R5 to make all traffic toward 10.x.x.x will be redirected to R0 and R3:


on R4

(config)#ip route 10.10.1.0 0.0.0.255 10.10.0.1



and on R5

(config)#ip route 10.10.0.0 0.0.0.255 10.10.1.1


 To test the functionality, just shutdown f.e. interface Tunnel 2 on R0 and trace the route from R4 to 10.10.1.2, you will see that the path will be R0-R1-R3-R5.
If you allow the Tunnel 2 interface on R0 if you issue the command again you will see that the chosen path will be R0-R2-R3-R5

Howto: create a PPPoE testing environment in GNS3 with dynamips

In this howto I'll try to explain how to create a PPPoE infrastructure for testing purpose with GNS3.
I have spent a few time searching the net during my current ISCW exam studying without success....so this is my solution.
Please notice that the server-side configuration is not what you'll find out there (for instance no one in production environment I guess is using local database to authenticate users), but the target here is to test and practice configuring PPPoE client.

1) Open a new project in GNS3 and then create the following topology:

2) Configure the "provider" router with the following from configuration mode

hostname provider
vpdn enable

vpdn-group pppoe-test
 accept-dialin

 protocol pppoe

 virtual-template 11

exit



interface Virtual-Template11

 ip unnumbered FastEthernet0/0

 ppp authentication pap pppoe-test

 ppp authorization pppoe-test

 ppp accounting pppoe-test

exit

aaa new-model

aaa authentication ppp pppoe-test local

aaa authorization network pppoe-test local
 username pppoeuser password cisco20;

interface fastethernet 0/0

 pppoe enable

 no shutdown
 interface fastethernet 0/1

 ip address 192.168.93.3 255.255.255.0

 no shutdown

exit

end


debug vpdn event
 
 
3) Configure the "subscriber" router with the following:

hostname subscriber




interface FastEthernet0/0
 no ip address
 pppoe enable
 pppoe-client dial-pool-number 1
 no shutdown


interface Dialer1
 mtu 1492
 ip address 192.168.233.10
 ip nat outside
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp pap sent-username pppoeuser password cisco20;
exit
end
debug ppp authentication
debug pppoe events



After less than 30 secs you should see these messages on the console of the subscriber router:

*Mar 1 00:09:33.107: Sending PADI: Interface = FastEthernet0/0
*Mar 1 00:09:33.179: PPPoE 0: I PADO R:c203.0dfc.0000 L:c202.0dfc.0000 Fa0/0
*Mar 1 00:09:35.155: PPPOE: we've got our pado and the pado timer went off
*Mar 1 00:09:35.155: OUT PADR from PPPoE Session
*Mar 1 00:09:35.227: PPPoE 3: I PADS R:c203.0dfc.0000 L:c202.0dfc.0000 Fa0/0
*Mar 1 00:09:35.227: IN PADS from PPPoE Session
*Mar 1 00:09:35.239: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
*Mar 1 00:09:35.239: PPPoE: Virtual Access interface obtained.
*Mar 1 00:09:35.239: PPPoE : encap string prepared
*Mar 1 00:09:35.243: [0]PPPoE 3: data path set to Virtual Acess
*Mar 1 00:09:35.243: Vi1 PPP: Using dialer call direction
*Mar 1 00:09:35.247: Vi1 PPP: Treating connection as a callout
*Mar 1 00:09:35.247: Vi1 PPP: Session handle[4E00000A] Session id[0]
*Mar 1 00:09:35.247: Vi1 PPP: Authorization required
*Mar 1 00:09:35.251: Vi1 PPP: No remote authentication for call-out
*Mar 1 00:09:35.251: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state t o up
*Mar 1 00:09:37.163: Vi1 PPP: No authorization without authentication
*Mar 1 00:09:37.163: Vi1 PAP: Using hostname from interface PAP
*Mar 1 00:09:37.167: Vi1 PAP: Using password from interface PAP
*Mar 1 00:09:37.167: Vi1 PAP: O AUTH-REQ id 1 len 23 from "pppoeuser"
*Mar 1 00:09:37.475: Vi1 PAP: I AUTH-ACK id 1 len 5
*Mar 1 00:09:38.475: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state t o up
 
When the connection is initialized you should successfully ping 192.168.93.3 from subscriber router....