I see - many thanks. Back to my sys admin who is convinced it's my routing not his.....dunno how i'll tell him this!
Martin
"John A. Sullivan III" wrote:
> I don't recall the specifics of the original problem and confess that I
> did not have the time to examine it closely but felt empathetic to the
> "desperate" plea and wanted to at least give some pointer!
> By the internal device, I meant the one on the 192.168.0.0 network that
> you were trying to reach. My thoughts are less centered on your routing
> configuration than on the routing configuration on the other end. Does
> the device on the other end know how to get back to 192.168.201.0? -
> John
>
> On Wed, 2002-04-24 at 04:56, Martin Edward John Waller wrote:
> > John Sullivan wrote:
> >
> > >
> > >
> > > It looks like you're sending SYN packets but
> > > never receiving an ACK. My guess would be that
> > > the internal device does not know how to get to
> > > 192.168.201.0/24 or it does know but it knows
> > > wrongly, i.e., some router is sending the
> > > packets to some other path. Hope this helps -
> > > John
> > >
> > > > John A. Sullivan III
> > > > Group Technology Director
> > > > Nexus Management
> > > > +1 207-985-7880
> > >
> >
> > Ok - thanks. I'm not sure what is meant by 'the
> > internal device' but assuming routing is the issue
> > here's my setup and routing info at my end - is it
> > correct for what I'm trying to do?
> >
> >
> >
> > 192.168.0.*
> > ============194.216.251.1======194.216.251.254
> > -----------------------------
> > 212.46.128.11=========aaa.bbb.ccc.ddd
> > =========192.168.201.*
> > [private subnet [firewall
> > = left] [router = leftnexthop]
> > [internet] [router = rightnexthop]
> > [my static IP = right] [my private
> > subnet
> > I want to
> > access]
> > (masqueraded)]
> >
> > My masquerading script and ispec.conf are
> > attached.
> >
> >
> > Here's my routing table when connections me-fw1
> > and me-flo are up:
> >
> > netstat -nr
> > Kernel IP routing table
> > Destination Gateway
> > Genmask Flags MSS Window irtt
> > Iface
> > 194.216.251.1 212.46.128.11 255.255.255.255
> > UGH 0 0 0 ipsec0
> > 212.46.128.11 0.0.0.0
> > 255.255.255.255 UH 0 0
> > 0 ppp0
> > 212.46.128.11 0.0.0.0
> > 255.255.255.255 UH 0 0
> > 0 ipsec0
> > 192.168.0.0 212.46.128.11
> > 255.255.255.0 UG 0
> > 0 0 ipsec0
> > 192.168.201.0 0.0.0.0
> > 255.255.255.0 U 0
> > 0 0 eth0
> > 0.0.0.0 212.46.128.11
> > 0.0.0.0 UG 0
> > 0 0 ppp0
> >
> > And here's ipsec eroute:
> >
> > ipsec eroute
> > 0 192.168.201.0/24 ->
> > 192.168.0.0/24 => tun0x1002_at_194.216.251.1
> > 0 aaa.bbb.ccc.ddd/32 ->
> > 194.216.251.1/32 => tun0x1004_at_194.216.251.1
> >
> > Is this correct at my end? Should I add something
> > to my ipmasquerading script? Stumped...
> >
> > Thanks for any info!
> >
> > Martin
> >
> >
> > ----
> >
>
> > #!/bin/sh
> > #
> > # rc.firewall - Initial SIMPLE IP Masquerade test for 2.1.x and 2.2.x kernels
> > # using IPCHAINS
> > #
> > # Load all required IP MASQ modules
> > #
> > # NOTE: Only load the IP MASQ modules you need. All current IP MASQ modules
> > # are shown below but are commented out from loading.
> >
> > echo "Starting IP Masquerading..."
> >
> > # Needed to initially load modules
> > #
> > /sbin/depmod -a
> >
> > # Supports the proper masquerading of FTP file transfers using the PORT method
> > #
> > /sbin/modprobe ip_masq_ftp
> >
> > # Supports the masquerading of RealAudio over UDP. Without this module,
> > # RealAudio WILL function but in TCP mode. This can cause a reduction
> > # in sound quality
> > #
> > /sbin/modprobe ip_masq_raudio
> >
> > # Supports the masquerading of IRC DCC file transfers
> > #
> > #/sbin/modprobe ip_masq_irc
> >
> >
> > # Supports the masquerading of Quake and QuakeWorld by default. This modules is
> > # for for multiple users behind the Linux MASQ server. If you are going to
> > # play Quake I, II, and III, use the second example.
> > #
> > # NOTE: If you get ERRORs loading the QUAKE module, you are running an old
> > # ----- kernel that has bugs in it. Please upgrade to the newest kernel.
> > #
> > #Quake I / QuakeWorld (ports 26000 and 27000)
> > #/sbin/modprobe ip_masq_quake
> > #
> > #Quake I/II/III / QuakeWorld (ports 26000, 27000, 27910, 27960)
> > #/sbin/modprobe ip_masq_quake 26000,27000,27910,27960
> >
> >
> > # Supports the masquerading of the CuSeeme video conferencing software
> > #
> > /sbin/modprobe ip_masq_cuseeme
> >
> > #Supports the masquerading of the VDO-live video conferencing software
> > #
> > /sbin/modprobe ip_masq_vdolive
> >
> >
> > #CRITICAL: Enable IP forwarding since it is disabled by default since
> > #
> > # Redhat Users: you may try changing the options in
> > # /etc/sysconfig/network from:
> > #
> > # FORWARD_IPV4=false
> > # to
> > # FORWARD_IPV4=true
> > #
> > echo "1" > /proc/sys/net/ipv4/ip_forward
> >
> >
> > #CRITICAL: Enable automatic IP defragmenting since it is disabled by default
> > # in 2.2.x kernels. This used to be a compile-time option but the
> > # behavior was changed in 2.2.12
> > #
> > echo "1" > /proc/sys/net/ipv4/ip_always_defrag
> >
> >
> > # Dynamic IP users:
> > #
> > # If you get your IP address dynamically from SLIP, PPP, or DHCP, enable this # following option. This enables dynamic-ip address hacking in IP MASQ,
> > # making the life with Diald and similar programs much easier.
> > #
> > #echo "1" > /proc/sys/net/ipv4/ip_dynaddr
> >
> >
> > # Enable the LooseUDP patch which some Internet-based games require
> > #
> > # If you are trying to get an Internet game to work through your IP MASQ box,
> > # and you have set it up to the best of your ability without it working, try
> > # enabling this option (delete the "#" character). This option is disabled
> > # by default due to possible internal machine UDP port scanning
> > # vunerabilities.
> > #
> > #echo "1" > /proc/sys/net/ipv4/ip_masq_udp_dloose
> >
> >
> > # MASQ timeouts
> > #
> > # 2 hrs timeout for TCP session timeouts
> > # 10 sec timeout for traffic after the TCP/IP "FIN" packet is received
> > # 160 sec timeout for UDP traffic (Important for MASQ'ed ICQ users)
> > #
> > /sbin/ipchains -M -S 7200 10 160
> >
> >
> > # DHCP: For people who receive their external IP address from either DHCP or
> > # BOOTP such as ADSL or Cablemodem users, it is necessary to use the
> > # following before the deny command. The "bootp_client_net_if_name"
> > # should be replaced the name of the link that the DHCP/BOOTP server
> > # will put an address on to? This will be something like "eth0",
> > # "eth1", etc.
> > #
> > # This example is currently commented out.
> > #
> > #
> > #/sbin/ipchains -A input -j ACCEPT -i bootp_clients_net_if_name -s 0/0 67 -d 0/0 68 -p udp
> >
> > # Enable simple IP forwarding and Masquerading
> > #
> > # NOTE: The following is an example for an internal LAN address in the
> > # 192.168.0.x network with a 255.255.255.0 or a "24" bit subnet mask
> > # connecting to the Internet on interface eth0.
> > #
> > # ** Please change this network number, subnet mask, and your Internet
> > # ** connection interface name to match your internal LAN setup
> > #
> > /sbin/ipchains -P forward DENY
> > /sbin/ipchains -A forward -i ppp0 -s 192.168.201.0/24 -j MASQ
> >
> > ----
> >
>
> > # /etc/ipsec.conf - FreeS/WAN IPsec configuration file
> >
> > # More elaborate and more varied sample configurations can be found
> > # in FreeS/WAN's doc/examples file, and in the HTML documentation.
> >
> >
> >
> > # basic configuration
> > config setup
> > # THIS SETTING MUST BE CORRECT or almost nothing will work;
> > # %defaultroute is okay for most simple cases.
> > #interfaces=%defaultroute
> > #interfaces=
> > interfaces="ipsec0=ppp0"
> > # Debug-logging controls: "none" for (almost) none, "all" for lots.
> > klipsdebug=all
> > plutodebug=all
> > # Use auto= parameters in conn descriptions to control startup actions.
> > plutoload=%search
> > plutostart=%search
> > # Close down old connection when new one using same ID shows up.
> > uniqueids=yes
> >
> >
> >
> > # defaults for subsequent connection descriptions
> > # (mostly to fix internal defaults which, in retrospect, were badly chosen)
> > #conn %default
> > # keyingtries=0
> > # disablearrivalcheck=no
> > # authby=secret
> > # leftrsasigkey=%dns
> > # rightrsasigkey=%dns
> >
> >
> >
> > # connection description for (experimental!) opportunistic encryption
> > # (requires KEY record in your DNS reverse map; see doc/opportunism.howto)
> > conn me-to-anyone
> > left=%defaultroute
> > right=%opportunistic
> > keylife=1h
> > rekey=[sums to e4ac...]
> > # uncomment this next line to enable it
> > #auto=route
> >
> >
> >
> > # sample VPN connection
> > conn sample
> > # Left security gateway, subnet behind it, next hop toward right.
> > left=10.0.0.1
> > leftsubnet=172.16.0.0/24
> > leftnexthop=10.22.33.44
> > # Right security gateway, subnet behind it, next hop toward left.
> > right=10.12.12.1
> > rightsubnet=192.168.0.0/24
> > rightnexthop=10.101.102.103
> > # To authorize this connection, but not actually start it, at startup,
> > # uncomment this.
> > #auto=add
> >
> > #work
> > conn me-fw1
> > type=tunnel
> > left=194.216.251.1
> > leftnexthop=194.216.251.254
> > right=aaa.bbb.ccc.ddd
> > rightnexthop=212.46.128.11
> > keyexchange=ike
> > auth=esp
> > pfs=no
> >
> > conn me-flo
> > type=tunnel
> > left=194.216.251.1
> > leftnexthop=194.216.251.254
> > leftsubnet=192.168.0.0/24
> > right=aaa.bbb.ccc.ddd
> > rightnexthop=212.46.128.11
> > rightsubnet=192.168.201.0/24
> > keyexchange=ike
> > auth=esp
> > pfs=no
> >
> --
> John A. Sullivan III
> Group Technology Director
> Nexus Management
> +1 207-985-7880
> John.Sullivan_at_nexusmgmt.com
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:53 CEST