Craig Johnson wrote:

The only documentation I can point you to for the border_router option is the shell-script source that builds the firewall rules.

So when you use the border_router option, what is the setting for IPFILTER_SWITCH in network.conf?

I beleive it should be set to "router". Look at the three script files that setup networking for full details:


/etc/network.conf
/etc/ipfilter.conf
/etc/init.d/network

Hmm...I suspect the ISP will consider anything coming down the wire to you as bandwidth that counts towards any quota, but you'd know better than I.

Peer networking is uncounted bandwidth for our ISP. Common with many ADSL ISPs in Australia.

Hmm...if you're in Australia, maybe you can get Matthew Grant to comment on how the Border Router stuff works. I believe he's next door over in New Zeland. :)


There are several ways to do what you want, all of which will generally 'break' conventional firewall setups (ie: no out-of-the box solution for you...custom tweaking required). The two main options are:

1) Route internal private-IP traffic from Server1 to the firewall, and use the firewall as your IPSec gateway.

2) NAT or masquerade IPSec traffic from Server1 on the firewall.

Is there any particular reason you don't want to use the more conventional DMZ setup?:

Internet
     |
firewall - public IP DMZ subnet - Servers
     |
private IP
internal net

The firewall can then serve as a VPN gateway for your internal network, your servers are on a protected DMZ, and all your firewall rules are in one place (rather than split between the firewall and Server1), for easy maintanince.

I probably should mention that the server1 connected to internal
networks is a MS ISA server (hopefully not too much of a dirty word on
this list!), with two network cards.
#1 is a potential security risk, if your public IP network is running public servers (internal traffic is on the public IP network in the clear).

Given my internal network is separated from the public IP network by the ISA Server box (which is on both networks), is that still a problem?

The problem is if you simply route VPN traffic from your internal network to the firewall via Server1, the VPN traffic will be 'in the clear' when it passes through your public IP "perimiter network" with the other servers. Should any of these servers ever get compromised, it would be fairly easy to sniff this traffic, and with a bit of craftiness, pass directly through your Server1 ISA box and access most anything on the internal network (this is not due to the fact that it's a MS box, but due to the fact that Server1 is simply routing between two trusted networks (the internal net and the VPN), and a malicious box on your perimiter network can look like valid VPN traffic w/o much difficulty). You'll have to decide how much of a security risk this is in your situation.


I still think you should just ditch the MS ISA box (or at least don't use it to connect the internal network), and run with a more traditional DMZ setup with your internal network hooked directly to the firewall. This easily allows your firewall to function as a VPN gateway (and as a possible bonus, *ALL* internet traffic from your internal net will be coming directly from the firewall, so might be FREE given your ISP's bandwidth metering policy). Of course there could be valid reasons you can't do this that you haven't shared with us...I'm just going on the info you've provided in your emails.

--
Charles Steinkuehler
[EMAIL PROTECTED]


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to