We has tubez!

Thoughts from your friendly neighborhood CTO.
  • rss
  • Home
  • About

Juniper SSG Port Forwarding Gotcha

Matt | October 13, 2010 | 3:56 pm

So I’m working on migrating few routed IP’s which are attached to my company’s cable modem over to a CIDR block of IP’s provided by our ISP (COX Communications).

Here’s the situation, apparently there’s a limit to the number of WAN IP’s that can be attached directly to your cable modem. In this case COX says that it’s 8 (this is an arbitrary number, but whatever). If you need more, you need to procure what’s called a CIDR block. Basically this is a block of addresses which is outside the subnet range of you modem’s WAN IP. Your ISP will then next hop the CIDR to your WAN IP, and it’s your job to take it from there. So instead of being able to tack a switch between your modem and your router to be able to assign WAN addresses to your server’s network cards, we need to use a router which can translate the forwarded CIDR block requests.

GREAT! I have a very nice router already! Enter the Juniper SSG-140, which is being replaced by the SRX series of devices running JUNOS, I digress however, as that’s a post better left for another time.

We initially had a number of issues trying to duplicate features that are available when you have additional IP’s that are inside your WAN subnet. Features like MIP, VIP, and the ability to attach a WAN address directly to a server’s NIC. (I know this isn’t best practice, however we have a deployment of Office Communications Server 2007 non-R2, which requires that a WAN IP be present on the NIC serving the Audio / Video Conferencing role.)

I’ll be making another post on how to duplicate all of the above functionality a little later I promise, but this post is about a NAT-DST port forwarding gotcha I encountered on me being retarded.

When you normally setup your home router, you specify the source and destination port that you want requests to be forwarded to. This is most often referred to as port forwarding, however here’s where the gotcha happens. Say you translate port 80 on your WAN IP to port 8080 on your internal network, you would actually be doing port shifting. Forwarding as it comes to mind of most people means your taking the wan port and passing it to an internal server with the same port.

When dealing with enterprise switches, you’ll often run into Source port and Destination port when referring to policies and services to go along with those policies.

I made the mistake of thinking that the source port in the screenshot above was the source port of the WAN IP address.
It’s actually the source port of the originating computer, the destination port is the destination of their request.

So you can see that I want all ports from the source computer to be accepted when requesting ports 18082, 18086, and 18087 on my WAN IP.

Remember to read and understand your networking equipment or you’ll end up like me and spend a couple hours troubleshooting something that was as easy as this.

Comments
No Comments »
Categories
Work Related
Comments rss Comments rss
Trackback Trackback

Categories

  • Dell (3)
  • Equallogic (3)
  • Hak5 (9)
  • Misc Thoughts (4)
  • SAP (2)
  • VMware (4)
  • Work Related (19)

Recent Posts

  • VMware ESXi NTP Time Servers
  • Making the Business Case for Virtualization
  • EqualLogic Multipathing Extension Module V1.1 for VMware® vSphere Early Production Access Kit (EPA)
  • New Equallogic Arrays PS4100, PS6100, FS7500
  • VMware vSphere 5 VRAM Entitlement Changes

Tag Cloud

3cx 2008 access Cisco Dell equallogic ESX esxi firewall firmware freenas ip-pbx iscsi Linksys Mac Messenger nap napera network OCS2007 pfsense phone ps series R900 SAP security Server sip SPA SPA962 VMWare VOIP wd western digital Windows windows 2003
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox