Here's a question about the mechanics of how the PIX handles ARP (I think!)
Assume, just for example, I had a 'standard' PIX installation. 2 interfaces, inside and outside, on standard security levels. I've a number of external IP addresses I can use for services, but, of course, can only use 1 of these IP addresses on the PIX's outside interface.
I know that the PIX can handle outside->inside statics using either the outside interface (port mapping) or one of my other external IP addresses. So, I could have:
access-list allow_in permit tcp any host xx.xx.xx.1 eq www
access-list allow_in permit tcp any host xx.xx.xx.2 eq https
access-list allow_in permit tcp any host xx.xx.xx.3 eq smtp
access-group allow_in in interface outside
(I havent included the statics for brevity).
But- as I understand it, TCP-based connections require sender and receiver to know each others MAC addresses- correct?
So- and this may be a dumb question: as the only device that has a mac address in my scenario is the outside of my PIX, how do devices track what they are talking to?
This is not a dumb question. An interesting one, ofcourse. I haven't got your query completely but here is what I made some sense of it.
You's say TCP connection needs the MAC of source and destination but the PIX knows MAC of its immediate peers. So how does PIX track the TCP connection..??
Well, if the above summary is correct, you'd need to jump into the OSI model and become a data flowing from layer 7 to layer 1 to understand this. In the layer 4 TCP puts the application and its header details. In layer 3 the IP puts its header and in layer - 2 the scenario is changed. The source MAC will be the MAC of the origin where as the destination MAC would be the immediate L2 device (switch or router or firewall). Packet routing decission is made based on L3 header where as at each hop the L2 frame is rebuilt and CRC is computed (new CRC will be stamped). Hence the L3 information is not changed through out the transit but L2 keeps changing. PIX need not know the MAC of original source and destination. It would keep a track of the source MAC from where it received the frame and destination MAC to where it would send it. In a HA/load balancing situations, when a fail over occurs, the cluster is configured to either have a virtual MAC or grab the MAC of primary to maintain session and state of the connections.
Hope this helps... let me know if you need more information. Please rate this post if helpful.
I have, for example, a /28 netblock for my outside network, eg, 22.214.171.124/28. Local router IP is .14, PIX outside is .1, and I have .2 to .13 available for general use.
I'm using .1 on the PIX outside, so can set up statics and acls to allow traffic from out to in on this one IP address. Thats fine: .1 is then assigned to an actual physical interface. But I could also set up other statics and acls to allow traffic in on some of my unused external IP addresses, say forwarding ftp from .2 on the outside to 192.168.1.1 on the inside. So, when the local router wants to forward a packet from itself on .14 to .2, its got to use ARP to find the mac, yes? But as there is no physical interface for .2, what happens next?
I think what I'm really asking is: how does the router 'find' the mac for .2?
The firewall answers the ARP request for .2 with his own MAC address because he is NAT'ing for that address. He essentially owns it as far as anything on the outside interface is concerned. So, if you were to look in the ARP cache of the router directly connected on the outside interface, both the .1 and .2 IP addresses would show the MAC address of the firewall's outside interface.
Thanks for the rating Gary. I could see that your query is already answered but hope your don't mind some more light on the issue..
You wanted to know what and how does the router know which is the MAC for .2? It need not know the actual MAC for .2. As I explained earlier.. routing comes into picture here. As static and ACLs are configured on PIX, there would be a conn and xlate table that map the external IP to the local IP. To the outside world, PIX boasts that it is .2 (besides .1). So router becomes a fool here forwarding packets for both .2 and .1 (and anyother, if static is configured) to PIX itself. This is the real essence and advantage of L3 over L2. L2 cannot be fooled easily in a network but L3 could. So PIX virtually maps itself to multiple IPs with one NIC.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...