https traffiic on a PIX 515

Jul 31, 2005 6 Replies

I've gotten most of the problems with my PIX 515 resolved, but I have one remaining. I can get normal http (www) traffic to cross from a low security interface (outside) to a higher security interface (inside) and back. But I can't do the same for https traffic. Since the traffic originates on the outside, I'm guessing the problem is my access-list / access-group is the problem. That is, I seem to have resolved all the other issues.



Here's my access list. It's not very tricky. The idea is to permit packets to the subnet where the www and https traffic is intended to go



access-list web permit tcp any XXX.XXX.XXX.0 0.0.0.255 eq www access-list web permit tcp any XXX.XXX.XXX.0 0.0.0.255 eq https access-list web permit ip any any



And to allow it in from the outside.



access-group web in interface outside



I done a lot of debug packet testing. And so I know that the www and https packets arrive at the outside interface. The www packets cross the PIX, and exist the inside interface, but https packets never do. I don't get it.



Thanks in advance for any help.



B Squared


I typed the access-list from memory, not from having it in front of me. So I think I was in fact using 255.255.255.0. Because the PIX passes the www traffic just fine, also makes me think I'm using the

255.255.255.0 netmask. However, thanks for pointing this out. I've also used "access-list web permit tcp any any eq https" rather than the network / netmask combination.

I'm still at a loss about the https traffic. Hmmm, ... I'm using https in the access-list because the destination port is 443. Does https depend on some other port in addition to port 443?

Thanks for you help.

B Squared

In article , wrote: :I've gotten most of the problems with my PIX 515 resolved, but I have :one remaining. I can get normal http (www) traffic to cross from a low :security interface (outside) to a higher security interface (inside) and :back. But I can't do the same for https traffic.

:Here's my access list. It's not very tricky. The idea is to permit :packets to the subnet where the www and https traffic is intended to go

: access-list web permit tcp any XXX.XXX.XXX.0 0.0.0.255 eq www : access-list web permit tcp any XXX.XXX.XXX.0 0.0.0.255 eq https : access-list web permit ip any any

The netmask is wrong for the PIX -- it should be 255.255.255.0 . The first two statements are effectively not going to be used, so it's down to the permit-everything third statement.

This doesn't explain why https isn't traversing your interface, though.

In article , wrote: :I'm still at a loss about the https traffic. Hmmm, ... I'm using https :in the access-list because the destination port is 443. Does https :depend on some other port in addition to port 443?

No.

I can't think offhand, though, of how https sidesteps the need for IP+port rewrites that are present in the http protocol. But then I have not ever really looked at how https works.

I am using static NAT, and addresses are mapped 1 to 1, so I don't think NAT is the problem. But thanks for the idea.

B Squared

What about static NAT statements? Because of that you haven't posted all the configuration I supposed you mapped an external address 1 to 1 to an internal one. Is it true or perhaps have you forwarded only port 80?

Alex.

Inorder for you to use ACL you also need a Static cmd to match the given server. Also for SSL, you need one public IP pr server/site.

So inorder for anyone to help you, you need to post your show static output. Also, ofcourse, you need to have a route statment to route traffic to the host. hth Martin Bilgrav

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required