Hello List..
It is the first time that I write. I am of Argentinean and my English is not
good..
Am I to install WISP and did he/she want to know if he/she already has
incorporate the possibility to use DHCp..?
Thank you..
---
This sf.net
Charles S. wrote:
I understand your logic, but what are you doing that kills the
connection? You should be able to play with IPSec tunnels
all day long
w/o messing up the main external uplink...
Some of the changes I tried were tweaking the CLAMPMSS in shorewall and
CLAMPMSS and mtu
Chris Low wrote:
EXTERN_TCP_PORTS=0/0_25
to allow anyone on the internet to send you e-mail, and you'll probably
have a lot better luck.
Did it and still not receiving. Also tried Mike's suggestion to remove the
$ from INTERN_SERVERS=tcp_$192.168.1.2_smtp_10.10.10.200_smtp. Backed up
the
Victor B. Berdin wrote:
Hello everyone,
I've upgraded my DS 2.2.19 to 2.2.20 and built the current FSwan1.99
with x509 to my kernel. Everything works fine if I were to use FSwan to
FSwan Sub2Sub VPN (either by PSK or RSA/Certs).
My problem is that, when I InterOp my LRP machine to a WIN2K, a
Victor B. Berdin wrote:
Hello everyone,
...and here are snips from my barf, wherein the last 2 lines of my auth.log
suggests a known problem with WIN2K being able to operate using 3DES,
then secretly revert to 1DES as discussed in this link:
How do I allocate more space to the /dev/root ram disk?
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 6144 607272 99% /
tmpfs1525616 15240 0% /tmp
tmpfs 2048 300 1748 15%
How do I allocate more space to the /dev/root ram disk?
The syst_size Parameter to the kernel, as described in the docs
add it to the kernel start line in syslinux.cfg
linux ... PKGPATH=/dev/hdc1 syst_size=20M ... etc.
- Alex
---
This
Thanks a ton!! I'd searched all over, but apparently not in the right
places.
- Todd
-Original Message-
From: Alex Rhomberg [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 10:20 AM
To: Todd Pearsall; [EMAIL PROTECTED]
Subject: AW: [leaf-user] Bering Ramdisk sizes
On Wednesday 12 February 2003 10:44 pm, Tom Eastep wrote:
snip
Here is the connection tracking table:
udp 17 177 src=192.168.1.1 dst=12.77.140.250 sport=1347 dport=1193
src=12.77.140.250 dst=12.243.227.207 sport=1193 dport=1347 [ASSURED] use=1
udp 17 179 src=192.168.1.1
On Wednesday 12 February 2003 07:24 pm, David Pitts wrote:
Lynn, maybe you mean me, not 'Dan'??
Anyway, I was/am using a Bering stable 1.0 with ezipupdt.lrp and
BPALogin.lrp. I deleted some packages I didn't need like bridge.lrp,
keyboard.lrp, ppp.lrp and pppoe.lrp. I also had pump and
I have been trying (unsucessfuly) to connect to a VPN server using Cisco
VPN client version 3.5.1 (B). The VPN client is running on win98
machine which is networked to a Dachstein LRP box.
I have found a series of e-mails in the archive from Rob Fegley dated 21
Dec 2002. Among the replies to
On Thursday 13 February 2003 09:55 am, [EMAIL PROTECTED] wrote:
I have been trying (unsucessfuly) to connect to a VPN server using Cisco
VPN client version 3.5.1 (B). The VPN client is running on win98
machine which is networked to a Dachstein LRP box.
I have found a series of e-mails in the
[EMAIL PROTECTED] wrote:
I have been trying (unsucessfuly) to connect to a VPN server using Cisco
VPN client version 3.5.1 (B). The VPN client is running on win98
machine which is networked to a Dachstein LRP box.
I have found a series of e-mails in the archive from Rob Fegley dated 21
Dec
On Thursday 13 February 2003 08:15 am, Todd Pearsall wrote:
- I successfully mapped a Windoze share (champagne corks flew), but it
would hang when I tried to get a directory listing
- I tired to view a web site on the distant end and the browser resolved
it and loaded part of the page, but
Ok, let's look at the base of you connection.
The remote end works flawlessly when connecting to your
subnet, correct?
Yup
On your subnet, you can map a share but transfers generally
bomb out, correct?
The local end can map a share, but transfers hang. Ftp connect,
transfers hang, etc.
On Thursday 13 February 2003 10:58 am, Todd Pearsall wrote:
I'll bet my desktop that your running Win2k/XP Pro/Server on
the local end
AND not on the remote end. If so, you can thank Bill G. for
breaking the DNS
and WINS rfc's for your problem.The integration of these two
services in
Todd Pearsall wrote:
You're close, except it's Windoze at both ends.
Doesn't work: Local WinXP to Remote WinNT Server
Works: Remote WinXP to Local Win2000 Server
Check into this at some of the MS FAQ sites. I think there are some
issues when connecting XP to NT4 servers (XP machines can't be
Todd Pearsall [EMAIL PROTECTED] schrieb:
Another note I wanted to repeat just in case it was important and
overlooked in my 1st message of this lengthy thread. When I restart
PPPoE (locally), in the course of the connection establishing I get
messages to the effect of Cant't increase MTU to
Welcome to the list. People are nice here, and
we'll try to take the time to get your system
running.
I have not used WISP, so you will have to wait
for a specific answer to your question.
Most people use Bering rather than WISP, and you might
try it yourself. There might be more documents
On Thu, 2003-02-13 at 09:35, Charles Steinkuehler wrote:
Todd Pearsall wrote:
You're close, except it's Windoze at both ends.
Doesn't work: Local WinXP to Remote WinNT Server
Works: Remote WinXP to Local Win2000 Server
Check into this at some of the MS FAQ sites. I think there are some
Check into this at some of the MS FAQ sites. I think there are some
issues when connecting XP to NT4 servers (XP machines can't
be added to
NT domains or something like that)...part of the MS forced upgrade
strategy. IIRC, you can get it to work, but you have to be
very careful
On Thursday 13 February 2003 01:44 pm, Todd Pearsall wrote:
Once I get any traffic moving I'm better prepared to fight the MS stuff.
That's why I'm using ftp as my test (how bad can M$ mess that up?)
Real bad if your using a Win2K/XP Pro workstation. When 2K first came out
I added a couple of
Below are tcpdumps from the eth1 and then the ipsec0 interfaces. Any
help in making some sense would be great. Let me know if other options,
test, etc. would be more useful. If it gets too wrapped in e-mail I can
make it available on the web.
Thanks.
- Todd
User on the local end makes a FTP
Todd Pearsall wrote:
Once I get any traffic moving I'm better prepared to fight the MS stuff.
That's why I'm using ftp as my test (how bad can M$ mess that up?)
Now there's a baited question. I'll keep my response civil, and point
out that that's what your traffic sniffer is for. :)
BTW:
A couple more detailsOn the local end I've used 3 different machines
(my XP laptop that works over the VPN from any of the other locations,
local XP laptop that belongs to one of the folks at the local site,
local end W2K server) so I don't *think* it's a local machine issue.
The totally
Todd Pearsall wrote:
Below are tcpdumps from the eth1 and then the ipsec0 interfaces. Any
help in making some sense would be great. Let me know if other options,
test, etc. would be more useful. If it gets too wrapped in e-mail I can
make it available on the web.
It's not too hard to piece
I had never considered the remote end. Just for grins I put
overridemtu=1200 on the remote end ipsec.conf and low and behold data
transfers!!!
I suspect I have patched the problem, but not addressed it. Does this
change any of the steps I should be doing to continue troubleshooting or
should
Todd Pearsall wrote:
I had never considered the remote end. Just for grins I put
overridemtu=1200 on the remote end ipsec.conf and low and behold data
transfers!!!
I suspect I have patched the problem, but not addressed it. Does this
change any of the steps I should be doing to continue
Charles Steinkuehler wrote
Using overridemtu may not be the best solution, but I think it should
work properly. While it doesn't look like it's possible to set
overridemtu on a per-connection basis, clamping *ALL* VPN
traffic to an
MTU that fits through the PPPoE links wouldn't be too
There's obviously Pitts' everywhere!!
I'm using the three interface Shorewall config (which, once I'd figured
out how to set rules, works beautifully and easily), no ipsec. Eth1 is
on 192.168.1.0, eth2 on 192.168.2.0.
David Pitts
IT Services Manager
Reid Library
University of Western Australia
Todd Pearsall wrote:
Charles Steinkuehler wrote
Using overridemtu may not be the best solution, but I think it should
work properly. While it doesn't look like it's possible to set
overridemtu on a per-connection basis, clamping *ALL* VPN
traffic to an
MTU that fits through the PPPoE links
On Thursday 13 February 2003 09:46 pm, [EMAIL PROTECTED] wrote:
Lynn,
I found your ipsec.txt, thanks.
One questioncould you give me an example of how to use ipfwd to
forward the port to my internal network. My LRP box is at 192.168.1.1
with gateway at 192.168.1.254 and I am using
Are any LEAF participants attending OSCON this year? If so, are any of you putting a
proposal to do a presentation on LEAF?
If the answer to the second question is no, I will be submitting a proposal for either
a 45min or 90min presentation by tomorow afternoon.
I have not been that
33 matches
Mail list logo
