Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Contivity 1100 configuration help 3

Status
Not open for further replies.

owee69

Programmer
Feb 28, 2005
20
US
I am setting up 2 Contivity 1100's, one at each end of a point-to-point T1 for data traffic. I need a really simple setup (no VPN, etc.), but I can't seem to get it to work. On one, I have configured:

LAN interface: 192.168.11.1 255.255.255.0 "private"
WAN interface: 192.168.10.2 PPP T1 "public"
default route: 192.168.10.1
RIP enabled on all
no firewall

...and on the other which has existing internet access:

LAN interface: 192.168.1.4 255.255.255.0 "private"
WAN interface: 192.168.10.1 PPP T1 "public"
default route: 192.168.1.1 (the existing Sonicwall firewall)
static route: 192.168.11.0 to 192.168.10.2
RIP enabled on all
no firewall

The problem is that, with my laptop plugged straight into the LAN interface, I can't even ping the WAN PPP IP of the Contivity I am plugged into.

I'm sure there is some sort of firewall setting to allow public to private traffic, but I cannot find it anywhere.
 
What version of code are you running?

There are two issues here most likely:
For untunneled traffic..
1-In order to route between the public and private interfaces, one must have the stateful firewall license.

2-There is no dynamic routing allowed on untunnelled interfaces on the Contivity (RIP being one of those).
My understanding is this will change in V 6.0 (however, I don't have confirmation whether that happened or not)

My recommendation would be (in order):
1- Need to purchase the FW License
2- Go static routes instead of RIP
 
Set both interfaces as private, and turn on Contivity fw.
(turn of NAT)

When you change the interface to private,you need to reboot.


This should work, it works for me..
 
This is partially correct. You do not need the Stateful Firewall Key. If you want to use the Stateful Firewall, you *do* need the key, but the other firewall option are the Interface filters, which do not require the key to be installed.

With the information you have given here it is clear that you need to enable the firewall. The Contivity will NOT pass traffic between interfaces without a firewall. I am speaking of one convity here. In other words, if you hang a PC on the private side of a contivity and try to ping something on the public side of that contivity, you will fail unless one of the firewalls is enabled and set up to pass traffic. This is true regardless of whether the interface is set to public or private. So for you to send traffic from the private side of one contivity through to the private side of another contivity (without a tunnel), you must have some kind of firewall enabled and configured on BOTH contivities.

It is correct that the Contivity will not allow dynamic routing protocols over a public interface. If you must use RIP (or OSPF), you must either set the public interface to be private (understand the security implications in doing this before you do it) or set up a tunnel between the two public interfaces so that dynamic routing can be used.
 
VPN Steve,
So have you tested this with interface firewalls?
I would be interested to hear of your findings.

I would be glad to hear that you can, because I have no issues using the interface firewall and corresponding filters if need be.

This would certainly save $$$...and also, it will give us a legitimate gripe to Nortel who has said it can't be done
(silly me for trusting them!) and has prompted us to provide the Stateful FW to lots of end users.

Thanks for your insight.

-HH
 
I've done this several times, but to be sure, I set this up in my lab today. Interface filters work just fine to pass traffic between interfaces, and do not require the Stateful Firewall Key. I'll go into that more later.

The setup: I set up two Contivity boxes as close to the setup the original poster described. I also did some variations.

With all interfaces set to private and RIP enabled and configured, no traffic would pass with the firewall disabled. I enabled the firewall, specifically the interface filters, set them to 'permit all' (a reboot is required), and traffic passed with no problem.

I then set the interfaces to public, changing nothing else. The interface filters were still enabled and set to 'permit all'. No traffic would pass, because RIP will not work on public interfaces. Once I set up static routes traffic would once again pass. The static route specified the ip subnet of the far side of the opposite contivity, with the gateway being the public interface ip address of the opposite contivity.

I also confirmed today that there was no change to version 6 code to allow dynamic routing on a public interface.

In summary, you can pass traffic between the two contivities without the Stateful Firewall being enabled if you use the interface filters. If you do it with the interfaces set to private, then you can also set up RIP (or OSPF) to make things easy. If you need to keep them public, then you can set up static routes.

I did want to say something about the difference between the Stateful Firewall and the Interface Filters. While it sounds great that you can pass traffic using the Interface Filters instead of the Stateful Firewall (and not pay for the Key), there are some very good reasons for using the Stateful Firewall.

Let's say that you are using the Interface Filters. A packet comes in to the Contivity. That packet is taken and checked against every filter before it is passed. Another packet comes in. It is checked against every filter before it is passed. This is assuming, of course, that it passes all the filter rules. With the interface filters, every packet is checked against every filter.

Now let's look at the Stateful Firewall. A packet comes in to the Contivity. It is checked against all the firewall rules before it is passed. However, before it is passed, a state is set. Every packet that comes in from that same stream is checked against that one state, and not against every firewall rule. I am obviously leaving a lot out here for the sake of simplicity.

The difference in the way the two firewall options operate give a huge advantage to the Stateful Firewall. The way the Stateful Firewall operates removes a huge amount of overhead from the CPU. You might not notice a difference on a box that is not under very much load, but at moderate to heavy load, it makes a *big* difference.

Like I said, I'm leaving a lot out, there are other advantages and differences, but that's probably the biggest.
 
Steve,

Yes, very familiar with the difference between packet inspection vs. stateful firewalls. I always recommend the stateful FW, but as you probably know, there are times when customers:
A)Already have a stateful firewall in place
B)Can't afford the Stateful firewall licenses...in these cases, I almost always recommend IpSecing into the box anyway. No need to elaborate there.

That being said, I am very dissappointed to hear
"I also confirmed today that there was no change to version 6 code to allow dynamic routing on a public interface."
Although I'm not surprised.

I have a call into Nortel to inquire about this especially since 6.0 was advertised as doing such.

It is possible that they ditched the idea once they purchased Tasman.

I will let you know what happens.
 
OK- found an answer.

Yes, there is dynamic routing support for public interface routing w/o stateful firewall, however, OSPF and RIP are not supported! Go figure.

Only BGP is allowed and one needs a license to enable it.
(It's new)

No one will be doing BGP on any 1100/10x0/600 series product anyway...this is designed for the 5000 series most likely.
 
You know, I checked on OSPF and RIP and totally blanked on checking on BGP. Good catch HungryHouse.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top