You are correct about the IP, for some odd strange reason my home IP ends in ".0" first time I'd seen that, I didn't think about the netmask being different. I'll play with that later tonight. I've got to setup the box now for the vendor to get in. I'll post my findings to you later...
Joey -----Original Message----- From: Ray Olszewski [mailto:[EMAIL PROTECTED]] Sent: Friday, August 16, 2002 9:41 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [leaf-user] allowing internal connections w/o IPSec Joey -- This is just a wild guess, but ... might you be specifying the remote IP address incorrectly? I can't tell from your latest presentation of it, since you report the lines as EXTERN_UDP_PORTS="0/0_1494 0/0_17" EXTERN_TCP_PORTS="remote.ip.add.ress/32_1494" But in your earlier message, you listed corresponding lines as EXTERN_TCP_PORTS="24.167.33.0/32_1494" EXTERN_UDP_PORTS="24.167.33.0/32_1494 Now addresses that end in .0 are *usually* network addresses, not host addresses. So I wonder if your remote source is really something like 24.167.33.0/24 or 24.167.33.0/28 ... or *some* netmask other than 32. If so, that might explain why 0/0 on the UDP line lets the connection work, but remote.ip.add.ress/32 does not. As I said, only a guess, since I am unfamiliar with the actual service. At 08:31 AM 8/16/02 -0500, Joey Officer wrote: >While I didn't get this detailed, I have been able to accomplish (atleast in >testing) what it was that I wanted. The following is the additions that I >made, only the relevant parts of each definition will be listed. > >network.conf >EXTERN_UDP_PORTS="0/0_1494 0/0_17" >EXTERN_TCP_PORTS="remote.ip.add.ress/32_1494" >INTERN_SERVERS="tcp_external.ip.add.ress_1494_internal.ip.add.ress_1494" >INTERN_AUTOFW0="-A -r udp 1494 1694 -h internal.ip.add.ress" > >svi network reload > >ipchains -I INPUT 1 -s remote.ip.add.ress/32 -d external.ip.add.ress/32 >1494 -p tcp -j ACCEPT >ipmasqadm portfw -a -P tcp -L remote.ip.add.ress 1494 -R >internal.ip.add.ress 1494 > > >After all of the above I can get it to work. However, there are a couple of >things that I don't like about this setup. First is the very first >EXTERN_UDP line. When I changed it from 0/0_1494 to specify the exact IP >address, it would no longer work. Once I changed it back to world open, it >would work. This really puts my network at a risk. There are a couple of >fail safes I guess, using hosts.allow and hosts.deny, but it still seems a >little wrong to me. Secondly, I can only make this available (the first >time) manually, I do not know how to add the above ipchains to something >more automated. And in reference to the ipchains command, I get an error >"ipchains: No target by that name". Although it still works, I'd like to be >able to remove the error and make it more automatic, in case of power >failure. > >I'm still open to suggestions, I have an hour or two this morning before I >have to really make it available to vendor. Any thoughts from the list? [old stuff deleted] -- -------------------------------------------"Never tell me the odds!"-------- Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] ---------------------------------------------------------------------------- --- ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ 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
