-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am not all that familiar with Smoothwall, but I have been very happy with the openVPN addon for IPCop. Likely your smoothwall documentation will be your best bet, along with their forums.
Evan Brown wrote: > I was just wondering about that myself, I haven't done any VPN'ing > myself ever and I would have to look at it but I know that smoothwall > has the capability. That may be the easiest thing to do or hardest...:) > I will definately look into that thanx for the idea. > > Evan >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Why not use a VPN? This way the client always uses the internal IP? >> >> Just a thought. >> >> Cheers, >> >> >> Evan Brown wrote: >> >>> There is no orange zone, we have 1 windows server that handles dhcp, >>> source safe ( source code control ) and dev databases. When we are all >>> in the office this isn't a big deal but when we have to go out of the >>> province or whatever to install software or whatever we have to use >>> source offsite which interacts with our source safe install. Before we >>> can go offsite you have to do a get on all the source you will be >>> working on thru source offsite because we've discovered that it causes >>> problems if we use source safe's client and just try to switch to source >>> offsite's client. They play together but they don't like to be swapped >>> around. Source offsite was originally registered to a certain ip and it >>> uses that to create some ID that is used when it locks code for check >>> out or whatever. If we check things out locally with offsite and hit the >>> server from 192.168.xxx.xxx then the ID is different when we hit it from >>> the red zone 205.xxx.xxx.xxx sooo we need to be able to hit that red >>> zone ip from the green to get around these problems. I know next to >>> nothing about configuring iptables and need a fairly hand holding >>> experiance. I've been cruising around the forum form smoothwall and >>> google and I came up with that example but I'm not sure about it does or >>> where in the file I insert it. >>> >>> Evan >>> >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Its funny I am having the same issue with one of my clients (only they >>>> have an expensive Sonicwall appliance). The solution for them was to >>>> have a host entry on the proxy server point to the internal IP, which >>>> worked fine as theirs was a web app. >>>> >>>> For you, the iptables code below looks like it might work, but iptables >>>> can mangle the packets which may still break your application (if there >>>> is some sort of encryption or authentication key, NAT may be of no >>>> help), I would need more information about your specific needs to be >>>> able to help. Do you have an Orange (DMZ) network set up? This might >>>> not be a bad approach, if this app resides in the DMZ, then everyone >>>> sees the same IP. Actually this is the point of a DMZ. >>>> >>>> On another, mostly unrelated note, I have been impressed with pfsense >>>> (http://www.pfsense.org) a fork of MoNoWall, but pf is a different beast >>>> from iptables altogether (it is the BSD equivalent to netfilter aka >>>> iptables). >>>> >>>> Evan Brown wrote: >>>> >>>> >>>>> I found this on the smoothwall site in the forums and since I know >>>>> nothing about iptables, does this look like it will work? >>>>> >>>>> /Hi, i download and install Smoothwall 2 Express , only test the smooth. >>>>> with >>>>> a green and orange configuration ISDN and DSL is disable , via web >>>>> administration put forwardings from GREEN to ORANGE zone and these rules >>>>> not working , via ssh execute iptables -t nat -L and i dont view my >>>>> rule.... but if i edit >>>>> the rc.firewall.up and put manually the rules >>>>> >>>>> "/sbin/iptables -t nat -A PREROUTING -p tcp -i $GREEN_DEV -d 10.1.1.229 >>>>> --dport 23 -j DNAT --to 192.168.77.2:23 " >>>>> "/sbin/iptables -A FORWARD -p tcp -i $ORANGE_DEV -d 192.168.77.2 --dport >>>>> 23 -j ACCEPT" >>>>> >>>>> /Evan >>>>> >>>>> the forward work and when execute iptables -t nat -L i view my rule, and >>>>> Then >>>>> >>>>> >>>>>> Thats the nature of the beast. I've seen this happen on a number of >>>>>> systems, including mine -- m0n0wall. >>>>>> I don't think IPCop has this flaw though. >>>>>> >>>>>> AFAIK, there is no way around it; of course, I could just be blowing >>>>>> smoke. >>>>>> >>>>>> Out of curiosity, why can't you just use the local IP? Why do you need >>>>>> to use the remote one? >>>>>> >>>>>> On 9/20/06, *Evan Brown* < [EMAIL PROTECTED] >>>>>> <mailto:[EMAIL PROTECTED]>> wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> I'm not sure if anyone is experienced with the Smoothwall fire >>>>>> wall but >>>>>> I have one setup and running well although I have a small problem >>>>>> from a >>>>>> usability stand point. I need to connect from my green zone to the >>>>>> red >>>>>> zone using the red zone IP address. We are currently port forwarding >>>>>> from red to green and that works fine outside of the lan but when >>>>>> we on >>>>>> the lan we can't hit the red zone ip. Any help would be appreciated. >>>>>> >>>>>> Evan Brown >>>>>> >>>>>> > > > _______________________________________________ > clug-talk mailing list > [email protected] > http://clug.ca/mailman/listinfo/clug-talk_clug.ca > Mailing List Guidelines (http://clug.ca/ml_guidelines.php) > **Please remove these lines when replying -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEbxUwRXgH3rKGfMRAtU8AJ9hiyplm++/+z6vRPSAh43/VNG2MgCcDJN5 Xo6BQKYjB3/y5RhVs6dYaX4= =+gIA -----END PGP SIGNATURE----- _______________________________________________ clug-talk mailing list [email protected] http://clug.ca/mailman/listinfo/clug-talk_clug.ca Mailing List Guidelines (http://clug.ca/ml_guidelines.php) **Please remove these lines when replying
