2

I am currently in the process of modifying how internet reaches my front end servers and I am having a strange issue with one of the existing stacks.

There is one physical firewall which is above the server, if I use this, I start recieving packet loss across the entire subnet, if I use wireshark I can see arp requests but I still get packet loss. The second I take this firewall out, the problem dissapear. If I route around the firewall straight to the front end server, I still do not get any issue.

All of this leads me to believe there must be something wrong with my config but I cannot see what for the life of me:

interface ethernet0 100full
interface ethernet1 100full
interface ethernet2 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security4
enable password ************ encrypted
passwd ************ encrypted
hostname sbc-cfw-02
fixup protocol dns maximum-length 512
no fixup protocol ftp 21
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719
fixup protocol http 80
no fixup protocol rsh 514
no fixup protocol rtsp 554
no fixup protocol sip 5060
no fixup protocol sip udp 5060
no fixup protocol skinny 2000
no fixup protocol smtp 25
no fixup protocol sqlnet 1521
fixup protocol tftp 69
names
name 10.17.2.0 as-net
name 10.17.2.1 sbc-fw-02-E1
name 10.17.2.2 sbc-as-01-E0
name 10.150.0.0 fe-net
name 10.150.0.221 sbc-fe-01-E1
name 10.150.0.222 sbc-fw-02-E0
name 10.150.0.223 sbc-as-01-nat
object-group service webstuff tcp
  port-object eq www
  port-object eq https
  port-object eq 8888
access-list inside_access_in permit icmp any any
access-list inside_access_in permit ip any any
access-list inside_access_in permit tcp any any
access-list inside_access_in permit udp any any
access-list inside_access_in permit tcp any host sbc-as-01-nat
access-list acl-web permit icmp any any
access-list acl-web permit tcp any any
access-list acl-web permit tcp any any object-group webstuff
access-list acl-web permit tcp any host sbc-as-01-nat eq ssh
pager lines 24
icmp permit any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside sbc-fw-02-E0 255.255.255.0
ip address inside sbc-fw-02-E1 255.255.255.0
no ip address intf2
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 10.150.0.1-10.150.0.210
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) sbc-as-01-nat sbc-as-01-E0 netmask 255.255.255.255 0 0
access-group acl-web in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 10.150.0.27 1
route outside 10.0.0.0 255.255.255.0 10.150.0.12 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80

The front end webserver (sbc-as-01) is on the 10.17.2.0 range, and the side having problems is the 10.150.0.* subnet.

Let me know if you need more information!

Mike Pennington
  • 8,266
  • 9
  • 41
  • 86
boburob
  • 1,174
  • 8
  • 23
  • When you say packet loss, do you mean 100% loss (there's no data traffic), or do you mean somewhere between 0-100%? When you say the side having the problem is on the outside - what do you mean? That packets going inside->outside are being dropped? But that outside->inside are not? It may be helpful to post your capture up at [http://cloudshark.org](http://cloudshark.org/)/ and then share the link here. What PIX version are you running? – sjw Jul 28 '12 at 12:17

1 Answers1

4

Chances are pretty good that you've got a mismatched speed / duplex setting on one (or both) of these links...

interface ethernet0 100full
interface ethernet1 100full

Almost all ethernet interfaces default to autonegotiation. If you have configured manual speed / duplex on these firewall interfaces, then autonegotiation on the other side will fail (usually falling back to 100-half). The mismatched duplex results in collisions (and thus packet loss). Just remove the manual speed / duplex settings on the Cisco...

There is no good reason to hard-code speed / duplex these days. In the early days of autoneg, it was not well-standardized; however, those days are long gone.

Mike Pennington
  • 8,266
  • 9
  • 41
  • 86