I have been working on a new network design. As part of the design I am using VLAN's to separate traffic. I want to create a special VLAN for true public IP addresses with no NAT'ing. The reason for this is in some cases vendors bring demo equipment in which requires public IP's with no NAT. I am a little puzzled how to create a public VLAN internally to achieve this. Does anyone have any suggestions on how to do this? Ideally when configured I will be able to switch any port to the public VLAN.
I can think of no real way of doing this. As you are doing this with VLAN's, you will be routing between layer 3 internal an external IP addresses.
You also need to have a range that is not being used on the internet, otherwise all your default routes will break this.
Honestly - I would question why external verndors need to have external IP addresses.....any demo can be reconfigured to use a "test" ip subnet.....10/8 gives you over 16 million available internal IP addresses....
Thanks for replying. I agree with your statement regarding the public IP's. I have had vendors bring in VTC gear to demo. I have configured one-to-one NAT and they still have problems. When I dig into it they have not been able to explain why there equipment does work. If I put them on a public IP then it works. Obviously there is something in the NAT that is causing a problem, but neither I nor their support has been able to resolve it. Trying to provide these public IP addresses would solve this issue and if I could do it via a VLAN I could tie it to any port. None the less I am not sure how feasible this is and much of a security risk it might make. Right now I am just trying to find a way to do this. I had thought GRE tunnels might be able to achieve this?
Thanks again for replying... Right now this is just in a lab environment. In my lab I am just using a 1841 router and that is were I have configured NAT. The production network will have an ASA5540 and NAT will be there. Coming into the network I will have a 3750 main switch, 3560's and 2960 switches.
Sounds like a problem between IP H.323 video conferencing and NAT. In addition to having source and destination IP addresses in the packet headers, H.323 embeds some source IP address info in the payload area. Not all router or firewall NAT implementations will recognize this; these will just change the source IP address in the packet header from a private IP to a public one, leaving the private IP address still embedded in the payload area. Then, when the remote video conference unit tries to return traffic to the embedded private IP address, it won't work.
Ask your vendors if their equipment can be manually configured to operate in a NAT environment. I work with a bunch of older Tandberg IP video endpoints that can be manually configured to embed the public IP address that the packets will be NATted to, in the payload area. That is, when they are used with firewalls or NAT devices that are not H.323-aware.
In cases where the router or firewall doesn't recognize the H.323 issue and compensate for it, and the video endpoint doesn't allow you to alter the IP address embedded in the payload area, then putting the video endpoint outside of your firewall is a common work-around.
If your firewall or perimeter security device is H.323-aware, like Cisco's ASA, then you don't need to embed the public IP address at the video endpoint. Just let the ASA handle it.
In addition to nailing up a 1-to-1 mapping of private to public IP address for the video unit, so people can initiate video calls to you, there are a bunch of port numbers that you need to allow through. Some will be TCP ports (for call setup/control) and some will be UDP (for audio and video data streams). The UDP ones are often dynamic in nature, changing during the call. You don't need to allow all 65,535 UDP port numbers through, although you can. Most vendors use specific port number ranges for their equipment; make sure you are allowing these through your firewall/NAT as well, and you should be fine.
Be careful about allowing certain ports, such as HTTP or SNMP, to the VTC. Some IP video conference equipment can be web-managed or reconfigured remotely. If you don't secure it properly, someone else will have fun doing it for you. ;-)
Hope this helps.
Please explain your internet segment topology.
Usually, the LAN facing connection in the internet router connects to a switch. On this segment, any device can hold a public IP address and route out to the internet without NAT.
If your internet router is also performing the NAT function /not a Firewall behind it/, then you can configure static NATs with the inside/outside being the same public IP address of the host sitting in the LAN side.
The closer in proximity you place the device to the internet router, the easier will be /avoiding routing/.
I suggest using a public range that is registered to your company. Use this as "test" network. This way you are sure that it won't break internet connectivity. I would strogly advise against using public ranges from your "demo" equipment vendors. If they can't change their ip addresses, they can do their demo on an ISOLATED vlan with no routing. You have to enforce some policies here.
Does your ISP provide a serial link range (X.X.X.X/30) and then a Public Range (X.X.X.X/28)? Ideally the layout I would see would be ISP(X.X.X.X/30) - (X.X.X.X/30) Outside - Internet Router - Inside - (X.X.X.X/28) - Public VLAN - Firewall/Vendor device, etc. Your firewall would then plug into the switch twice (once in the public VLAN to the outside interface and again to the private vlan with the inside interface).
The Internet router internal IP would patch to the segregated VLAN and that VLAN could be propagated throughout the network. Do not put anything you don't want on that VLAN including the switch. The switch can have the VLAN setup (Layer2), just don't assign an IP to the VLAN interface (Layer 3).
You would still need a form of NAT to take care of your internal network, however that should be a firewall and/or another router.
You could also do it with one device (2811 router) assigning an IP to your NAT pool and one to the network range that can patch off of the other port. I've done that as well, a little more complex, but it gets the job done.
Hope this helps, rate if it does,