Transparent firewall between PPPoE client and server

[joemhemail]

To learn arp-inspection and ethertype access-lists with transparent firewalls, I created a lab with a PPPoE client on one side of the 802-15 transparent firewall and a PPPoE server on the other side of the firewall. I can get the R1 PPPoE discover messages (ethertype 0x8863) to traverse the firewall, but wireshark shows the R2 PPPoE offer messages (ethertype 0x8863) not traversing the firewall and the show asp drop command on the firewall shows the Frame drop: unexpected packet to increase by one when the PPPoE offer message is received.The interfaces have the same security and same-security-traffic permit inter-interface is configured. If anyone could help, that would be great. I have given up.

802-15# sh run
: <snip>
:
ASA Version 8.0(2)
!
firewall transparent
hostname 802-15

!
interface Ethernet0/0
 nameif R1
 security-level 50
!

interface Ethernet0/4
 nameif PC
 security-level 50

same-security-traffic permit inter-interface

access-list R1-IN ethertype permit 8863
access-list PC-IN ethertype permit 8863

logging enable
logging buffered debugging
mtu R1 1500
mtu PC 1500
ip address 192.168.109.15 255.255.255.0

asdm image disk0:/asdm-649.bin

arp R1 192.168.109.1 c201.172c.0001
arp PC 192.168.109.253 c203.1af4.0001
arp PC 192.168.109.126 c203.1af4.0001
arp PC 192.168.109.2 c202.24f0.0020

access-group R1-IN in interface R1
access-group PC-IN in interface PC

http server enable
http 192.168.109.253 255.255.255.255 PC

arp-inspection R1 enable no-flood
arp-inspection PC enable no-flood
ntp server 192.168.109.126

R1#sh run int fa 0/1 | b inter

interface FastEthernet0/1
 no ip address
 ip tcp adjust-mss 1452
 speed 100
 full-duplex
 pppoe enable group global
 pppoe-client dial-pool-number 15
 no keepalive
 no cdp enable
 no mop enabled
end

R1#sh run int dialer 2

interface Dialer2
 description a temporary interface to generate PPPoE packets
 ip address negotiated
 ip mtu 1492
 encapsulation ppp
 dialer pool 15
 dialer idle-timeout 0
 dialer enable-timeout 1
end

R2#sh run | section bba-group
bba-group pppoe R1
 virtual-template 1

R2#sh run int virtual-temp 1 | b irtual
interface Virtual-Template1
 mtu 1492
 ip unnumbered FastEthernet2/0
 peer default ip address pool PPPoE
end

R2#sh run int fas 2/0 | b inter
interface FastEthernet2/0
 ip address 192.168.109.2 255.255.255.0
 speed 100
 full-duplex
 pppoe enable group R1
 no keepalive
 no cdp enable
 no mop enabled
end

R2#sh run | i local pool
ip local pool PPPoE 192.168.109.1

[Vibhor Amrodia]

Hi,

I think the ASP drops are expected as per the drop reason:-

Unexpected packet:

This counter is incremented when the appliance in transparent mode receives a non-IP packet, destined to its MAC address, but there is no corresponding service running on the appliance to process the packet.

Recommendation:

Verify if the appliance is under attack. If there are no suspicious packets, or the device is not in transparent mode, this counter is most likely being incremented due to a software error. Attempt to capture the traffic that is causing the counter to increment and contact the Cisco TAC.

Refer:-

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/S/cmdref3/s3.html#pgfId-1555034

I am not sure if this topology would be supported on the ASA device.

Did you try specific Ethertype ACL on the ASA device to allow this traffic.

Thanks and Regards,

Vibhor Amrodia

[joemhemail]

I have a clue. My packet captures show

1) On the link between R1 and 802-15, PPPoE (point to point protocol over ethernet) discovery source mac address c201.172c.0001 and destination mac address Broadcast

2) On the link between R2 and 802-15, PPPoE discovery source mac address 0000.ab61.0f04 and destination mac address Broadcast

3) On the link between R2 and 802-15, PPPoE offer messages are source mac address  c202.24f0.0020 and destination mac address 0000.ab61.0f04

The ASA in GNS3 has replaced the source mac address with it's own mac address and consequently R2 sends the PPPoE offer message to 802-15 instead of R1.

Now it's just a matter of time to determine whether or not there's a configuration command for the ASA that will prevent this behavior. I'll try a quck shot at modifying the ASA's MPF (modular policy framework) to see if that will work. However, this looks to be too advanced for me to try to solve at this time.