devil-linux-discuss — General Mailing List for all discussions

[Devil-Linux-discuss] Troubles with Telnet clients

[<ne...@co...>]

OK  I'd like to thank all those who have offered help.

I got a few suggestions about dropping the NAT--I'm way too new at all of this to take that hint and be able to just run with it.  There are two different options I am looking at.
----------------------------------------------------------------------------------------------------------------------------------------
Option #1
How would I modify the firewall.rules to allow for traffic to reach the telnet server without using NAT.  It is possible that the NAT is what is causing the telnet sessions to swap, get stolen by another user (please see thread if you need clarification on that one).

######################################################################
#accept DHCP
${IPTABLES} -A INPUT -p UDP -i eth1 --dport 67:68 -j ACCEPT
${IPTABLES} -A OUTPUT -p UDP -o eth1 --dport 67:68 -j ACCEPT
 
 
#allow access to the  server
${IPTABLES} -A FORWARD -i eth1 -p TCP -o eth0 -d $TELNETIP --dport 23 -j ACCEPT
${IPTABLES} -A FORWARD -i eth0 -p TCP -o eth1 -s $TELNETIP -m state --state ESTABLISHED,RELATED --sport 23 -j ACCEPT

#drop UDP packets
${IPTABLES} -A FORWARD -p UDP --dport 1: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport :21 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24:66 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 69: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24: -j DROP
 
#allow ping from WAN side only
${IPTABLES} -A INPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A OUTPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A FORWARD -p icmp -j DROP
${IPTABLES} -A OUTPUT -p icmp -j DROP

######################################################################
 
# Masquerading (aka NAT, PAT, ...)
######################################################################
${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
 ######################################################################


----------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------
2nd possibility (although I would prefer to get the first option working)

Another option I've been looking into is offering dhcp off of the red side.  I've managed to get a test system up and running.  DHCP is working on the red side; however I can't seem to get the telnet to forward through the firewall.  Started out with the default firewall.rules.2nic
green IP 10.3.10.9/255.255.0.0 gw 10.3.1.1
red IP 192.168.1.200/255.255.255.0 (DHCP server)
Telnet server IP 131.107.1.18/255.255.0.0
if I SSH into the DL box from either side, I can telnet to the server.  I can't seem to get the forwarding to work properly.

Block-A works--as long as Block-D is commented out (not ideal, since it prevents the red side from dropping some malicious/bad packets).

Block-C works perfectly.

Block-B does not work at all

Here's the changes:
#BLOCK-A############################################################################
#Accept DHCP
${IPTABLES} -A INPUT -i ${OUT_DEV} -p UDP --dport 67:68 -j ACCEPT
${IPTABLES} -A OUTPUT -o ${OUT_DEV} -p UDP --dport 67:68 -j ACCEPT
####################################################################################

# We accept anything from the inside.
${IPTABLES} -A INPUT -i ${INT_DEV} -j ACCEPT
${IPTABLES} -A OUTPUT -o ${INT_DEV} -j ACCEPT

# Allow our firewall to connect.
${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
${IPTABLES} -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Allow Ping and friends.
${IPTABLES} -A INPUT  -p icmp -j ACCEPT
${IPTABLES} -A OUTPUT -p icmp -j ACCEPT

# Fast reject for Ident to eliminate email delays.
${IPTABLES} -A INPUT -p TCP --dport 113 -i ${OUT_DEV} -j REJECT --reject-with tcp-reset

# Masquerading (aka NAT, PAT, ...)
${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE

#BLOCK-B############################################################################
# Uncomment/modify the next 4 lines to forward a service to an internal IP.
SERVER_IP=131.107.1.18	# Internal IP of server.
PORT=23		# 22 = SSH.  Change to 80 for web server, etc.
${IPTABLES} -A PREROUTING -i ${OUT_DEV} -t nat -p TCP --dport $PORT -j DNAT --to ${SERVER_IP}:${PORT}
${IPTABLES} -A FORWARD -p TCP -d ${SERVER_IP} --dport $PORT -i ${OUT_DEV} -o ${INT_DEV} -j ACCEPT
####################################################################################

#BLOCK-C###########################################################################
# Uncomment/modify the next 2 lines to open a port on the internet to Devil Linux.
PORT=22		# 25 = SMTP.  Change to the port you wish to open.
${IPTABLES} -A INPUT -p tcp --dport $PORT -i ${OUT_DEV} -j ACCEPT
####################################################################################

#BLOCK-D############################################################################
# Block invalid connections from the internet.
#[ -n "$LOGGING" ] && \
#  ${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j LOG --log-prefix "FORWARD INVALID:"
#${IPTABLES} -A FORWARD -m state --state NEW,INVALID -i ${OUT_DEV} -j DROP
####################################################################################

Here's the contents of the iptables -L on the test system.
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere            udp dpts:bootps:bootpc 
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            
REJECT     tcp  --  anywhere             anywhere            tcp dpt:ident reject-with tcp-reset 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             131.107.1.18		 tcp dpt:telnet 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     all  --  anywhere             anywhere            state NEW 

Chain OUTPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             anywhere            udp dpts:bootps:bootpc 
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state NEW,RELATED,ESTABLISHED 
ACCEPT     icmp --  anywhere             anywhere            

----------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------

I'd prefer to go with option 1 if it is possible to get it working.  We have a wireless network that can't be secured (due to the handheld barcode scanners and their limitations). 

thanks,
 

> 
> Message: 3
> Date: Thu, 19 Apr 2007 18:22:30 +0000
> From: ne...@co...
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> 	Issue 2
> To: dev...@li...
> Message-ID:
> 	
> <041...@co...>
> 	
> 
> There really is no reason to NAT.
> 
> The way this box was intended to operate is as follows:
> 1)DHCP the clients (192.168.0.x)
> 2)Don't allow anything but telnet to a specific server (no dns etc...)
> 3)Do not trust the clients.
> 
> In a lot of ways the firewall is backwards.  Since we have embedded telnet 
> clients (that can't be any smarter than they already are) we needed a way to 
> lock down our wireless without interfering with the normal operation of the 
> business.
> 
> I trust the network on the red side, but can't trust the wireless clients.  I'm 
> not sure if it would help, but I have the freedom to have up to 255 IP's set 
> aside on the network (red side).  Don't know if it would help to have the red 
> interface have multiple IP's etc...
> 
> Aside from not being an expert on this, I have no reason to stick with NAT.  I'd 
> be fine with modifying the config, but wouldn't know how to adjust it on my own.  
> Here's the relevant parts of the rules file.  Would it be as simple as dropping 
> the DNAT and nat portions from the rules?
> 
> ######################################################################
> #accept DHCP
> ${IPTABLES} -A INPUT -p UDP -i eth1 --dport 67:68 -j ACCEPT
> ${IPTABLES} -A OUTPUT -p UDP -o eth1 --dport 67:68 -j ACCEPT
> 
> #translate to our network
> ${IPTABLES} -A PREROUTING -i eth1 -t nat -p TCP -d 10.10.10.18 -j DNAT --to 
> $TELNETIP_NM
> 
> #allow access to the  server
> ${IPTABLES} -A FORWARD -i eth1 -p TCP -o eth0 -d $TELNETIP --dport 23 -j ACCEPT
> ${IPTABLES} -A FORWARD -i eth0 -p TCP -o eth1 -s $TELNETIP -m state --state 
> ESTABLISHED,RELATED --sport 23 -j ACCEPT
> 
> #drop UDP packets
> ${IPTABLES} -A FORWARD -p UDP --dport 1: -j DROP
> ${IPTABLES} -A INPUT -p TCP -i eth1 --dport :21 -j DROP
> #${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24:66 -j DROP
> #${IPTABLES} -A INPUT -p TCP -i eth1 --dport 69: -j DROP
> ${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24: -j DROP
> 
> #allow ping from WAN side only
> ${IPTABLES} -A INPUT -s $OUR_NW -p icmp -j ACCEPT
> ${IPTABLES} -A OUTPUT -s $OUR_NW -p icmp -j ACCEPT
> ${IPTABLES} -A FORWARD -p icmp -j DROP
> ${IPTABLES} -A OUTPUT -p icmp -j DROP
> 
> ######################################################################
> 
> # Masquerading (aka NAT, PAT, ...)
> ######################################################################
> #${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
> ######################################################################
> 
> -joseph
>  -------------- Original message ----------------------
> From: dev...@li...
> > Send Devil-linux-discuss mailing list submissions to
> > 	dev...@li...
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> > or, via email, send a message with subject or body 'help' to
> > 	dev...@li...
> > 
> > You can reach the person managing the list at
> > 	dev...@li...
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Devil-linux-discuss digest..."
> > 
> > 
> > Today's Topics:
> > 
> >    1. Re: Devil-linux-discuss Digest, Vol 11,	Issue 1
> >       (ne...@co...)
> >    2. Re: Devil-linux-discuss Digest, Vol 11, Issue 1 (Heiko Zuerker)
> >    3. Re: Devil-linux-discuss Digest, Vol 11,	Issue 1 (Fred Frigerio)
> >    4. Re: ADSL not connecting - more details (David Nicol?s Abdala)
> >    5. Re: ADSL not connecting - more details (Heiko Zuerker)
> >    6. need of tcptraceroute on devil (Philippe Weill)
> >    7. Fwd: openvpn tun problem (Jozsef Valkai)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Thu, 05 Apr 2007 19:19:33 +0000
> > From: ne...@co...
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > 	Issue 1
> > To: dev...@li...
> > Message-ID:
> > 	
> > 
> <040...@co...>
> > 	
> > 
> > Heiko, thank you for your quick reply.
> > 
> > > What do you mean exactly with swapping sessions?
> >  >I'm currently failing to understand where the DL box comes into play
> >  >(except for the firewalling).
> > 
> > Swapping sessions:
> > Each user logs into the telnet-based app.  
> > When they log in, they get specific menu options based on their logon. 
> > When one handheld "steals" a session, someone can power up a scanner and be 
> > logged in as someone else--or be logged in as someone else who might have been 
> > in the middle of an inventory transaction.  A good example of this might be 
> > where one person was adding to an outbound shipment at the same time someone 
> > else was receiving product.  Without warning the receiver's scanner was using 
> > the shipper's session.  That really messes up the transactions and can take a 
> > while to solve. 
> > 
> > 
> > The DL box:
> > This is how we are controlling the access to the network.  When we put the DL 
> > box in, the dozen or so clients connecting to the telnet server all seem to be 
> > coming from the same IP (the DL box).  Before the DL box, each of the scanners 
> > had their own IP that could be seen by the telnet server.  This means that it 
> > could restore a session if there was a disruption in our T1.  
> > 
> > Basically I'm looking for suggestions on how to keep the DL box in use without 
> > (or at least minimizing) the problems with the telnet clients. The DL box has 
> > prevented a number of people from hopping onto our wireless network and I'd 
> like 
> > to keep it.
> > 
> > -joseph
> > 
> > 
> > > 
> > > Message: 9
> > > Date: Thu, 05 Apr 2007 18:49:45 +0000
> > > From: ne...@co...
> > > Subject: [Devil-Linux-discuss] Telnet clients swapping sessions
> > > To: dev...@li...
> > > Message-ID:
> > > 	
> > > 
> <040...@co...>
> > > 	
> > > 
> > > Good Day everyone,
> > > 
> > > I've set up a DL (1.2) server that controls wireless access to our LAN. It 
> > runs 
> > > on a via c3 system.
> > > 
> > > The only purpose for the wireless is to allow handheld barcode scanners 
> (less 
> > > than a dozen embedded DOS telnet clients) to connect to one of our servers. 
> We 
> > > set the firewall rules to only allow for specific telnet traffic and dhcp 
> > > requests. 
> > > 
> > > All went fairly well for a couple of weeks.  Then we noticed that the 
> embedded 
> > > clients were swapping/stealing sessions.   Sometimes it would happen when 
> > there 
> > > was a glitch in our T1 etc...
> > > 
> > > Lately, things have gotten worse.  The handheld scanners are doing this 
> > several 
> > > times a day.   When one is powered on, for example, it sometimes steals the 
> > > session from another handheld.  This is a problem as users have different 
> > > permissions in the inventory software.  
> > > 
> > > If at all possible, the clients need to DHCP, and we need to keep the access 
> > as 
> > > tight as is possible.  Just going through the logs, I can see a dozen or two 
> > > foiled attempts to hop onto our network.
> > > 
> > > 
> > > I'll gladly provide more info since I don't know what info would help.
> > > 
> > > 
> > > 
> > > 
> > > ------------------------------
> > > 
> > > Message: 10
> > > Date: Thu, 5 Apr 2007 14:01:25 -0500 (CDT)
> > > From: "Heiko Zuerker" <he...@zu...>
> > > Subject: Re: [Devil-Linux-discuss] Telnet clients swapping sessions
> > > To: dev...@li...
> > > Message-ID:
> > > 	<295...@ga...>
> > > Content-Type: text/plain;charset=iso-8859-1
> > > 
> > > 
> > > On Thu, April 5, 2007 13:49, ne...@co... wrote:
> > > > Good Day everyone,
> > > >
> > > >
> > > > I've set up a DL (1.2) server that controls wireless access to our LAN.
> > > > It runs on a via c3 system.
> > > >
> > > >
> > > > The only purpose for the wireless is to allow handheld barcode scanners
> > > > (less than a dozen embedded DOS telnet clients) to connect to one of our
> > > > servers. We set the firewall rules to only allow for specific telnet
> > > > traffic and dhcp requests.
> > > >
> > > > All went fairly well for a couple of weeks.  Then we noticed that the
> > > > embedded clients were swapping/stealing sessions.   Sometimes it would
> > > > happen when there was a glitch in our T1 etc...
> > > >
> > > > Lately, things have gotten worse.  The handheld scanners are doing this
> > > > several times a day.   When one is powered on, for example, it sometimes
> > > > steals the session from another handheld.  This is a problem as users
> > > > have different permissions in the inventory software.
> > > >
> > > > If at all possible, the clients need to DHCP, and we need to keep the
> > > > access as tight as is possible.  Just going through the logs, I can see a
> > > > dozen or two foiled attempts to hop onto our network.
> > > >
> > > >
> > > > I'll gladly provide more info since I don't know what info would help.
> > > 
> > > What do you mean exactly with swapping sessions?
> > > I'm currently failing to understand where the DL box comes into play
> > > (except for the firewalling).
> > > 
> > > -- 
> > > 
> > > Regards
> > >   Heiko Zuerker
> > >   http://www.devil-linux.org
> > ------------------------------
> > 
> > Message: 2
> > Date: Thu, 5 Apr 2007 14:24:43 -0500 (CDT)
> > From: "Heiko Zuerker" <he...@zu...>
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > 	Issue 1
> > To: dev...@li...
> > Message-ID:
> > 	<272...@ga...>
> > Content-Type: text/plain;charset=iso-8859-1
> > 
> > 
> > On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > > Heiko, thank you for your quick reply.
> > >
> > >
> > >> What do you mean exactly with swapping sessions?
> > >> I'm currently failing to understand where the DL box comes into play
> > >> (except for the firewalling).
> > >>
> > >
> > > Swapping sessions:
> > > Each user logs into the telnet-based app.
> > > When they log in, they get specific menu options based on their logon.
> > > When one handheld "steals" a session, someone can power up a scanner and
> > > be logged in as someone else--or be logged in as someone else who might
> > > have been in the middle of an inventory transaction.  A good example of
> > > this might be where one person was adding to an outbound shipment at the
> > > same time someone else was receiving product.  Without warning the
> > > receiver's scanner was using the shipper's session.  That really messes
> > > up the transactions and can take a while to solve.
> > >
> > >
> > > The DL box:
> > > This is how we are controlling the access to the network.  When we put the
> > > DL box in, the dozen or so clients connecting to the telnet server all
> > > seem to be coming from the same IP (the DL box).  Before the DL box, each
> > > of the scanners had their own IP that could be seen by the telnet server.
> > > This means that it could restore a session if there was a disruption in
> > > our T1.
> > >
> > > Basically I'm looking for suggestions on how to keep the DL box in use
> > > without (or at least minimizing) the problems with the telnet clients.
> > > The DL box has prevented a number of people from hopping onto our
> > > wireless network and I'd like to keep it.
> > 
> > OK so you're currently hiding all the scanners behind a NAT right now.
> > Would it be possible for you to 'officially' route the IPs from the
> > scanners, without the NAT?
> > 
> > -- 
> > 
> > Regards
> >   Heiko Zuerker
> >   http://www.devil-linux.org
> > 
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Thu, 5 Apr 2007 15:30:25 -0400
> > From: "Fred Frigerio" <ffr...@lo...>
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > 	Issue 1
> > To: <dev...@li...>
> > Message-ID:
> > 	<CB8...@wi...>
> > Content-Type: text/plain;	charset="us-ascii"
> > 
> > It may sound obvious but you can DHCP and route one of the  non-internet
> > routable networks. Either 192.168.x.x/24 or even partition 10.x.x.x./8
> > into many /24 You can even superpose that IP network on another but then
> > you would have to assign the IP's to a given MAC address on the DHCP
> > server so you don't disturb your normal network. Another option is go
> > the vlan way which is probably cleaner but may need an upgrade of the
> > switches.
> > 
> > What is the reason to do NAT?
> > 
> > 
> > Fred Frigerio
> > Locust USA
> >  
> > This electronic message transmission contains information from Locust
> > USA which may be confidential or privileged.  The information is
> > intended to be for the use of the individual or entity named above.  If
> > you are not the intended recipient, be aware that any disclosure,
> > copying, distribution or use of the contents of this information is
> > prohibited.  If you have received this electronic transmission in error,
> > please notify us by telephone (305-889-5410) or by reply via electronic
> > mail immediately.
> > 
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf Of
> > Heiko Zuerker
> > Sent: Thursday, April 05, 2007 3:25 PM
> > To: dev...@li...
> > Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> > Issue 1
> > 
> > 
> > On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > > Heiko, thank you for your quick reply.
> > >
> > >
> > >> What do you mean exactly with swapping sessions?
> > >> I'm currently failing to understand where the DL box comes into play 
> > >> (except for the firewalling).
> > >>
> > >
> > > Swapping sessions:
> > > Each user logs into the telnet-based app.
> > > When they log in, they get specific menu options based on their logon.
> > > When one handheld "steals" a session, someone can power up a scanner 
> > > and be logged in as someone else--or be logged in as someone else who 
> > > might have been in the middle of an inventory transaction.  A good 
> > > example of this might be where one person was adding to an outbound 
> > > shipment at the same time someone else was receiving product.  Without
> > 
> > > warning the receiver's scanner was using the shipper's session.  That 
> > > really messes up the transactions and can take a while to solve.
> > >
> > >
> > > The DL box:
> > > This is how we are controlling the access to the network.  When we put
> > 
> > > the DL box in, the dozen or so clients connecting to the telnet server
> > 
> > > all seem to be coming from the same IP (the DL box).  Before the DL 
> > > box, each of the scanners had their own IP that could be seen by the
> > telnet server.
> > > This means that it could restore a session if there was a disruption 
> > > in our T1.
> > >
> > > Basically I'm looking for suggestions on how to keep the DL box in use
> > 
> > > without (or at least minimizing) the problems with the telnet clients.
> > > The DL box has prevented a number of people from hopping onto our 
> > > wireless network and I'd like to keep it.
> > 
> > OK so you're currently hiding all the scanners behind a NAT right now.
> > Would it be possible for you to 'officially' route the IPs from the
> > scanners, without the NAT?
> > 
> > -- 
> > 
> > Regards
> >   Heiko Zuerker
> >   http://www.devil-linux.org

Re: [Devil-Linux-discuss] Possible to make documentation on web site available for download?

[Mailing L. <mai...@co...>]

Bogdan, Ivan, and Heiko: Thanks to each of you, for replying to me!
Lanny in Colombia, South America

[Devil-Linux-discuss] SSHjail

[Bruce S. <br...@ar...>]

http://www.linux.com/article.pl?sid=07/04/11/211209

I like this idea!  Especially for people who allow "users" ssh access to
their boxes for some reason.  (like me :)

Anyone with any experience running something like this?

Is this the "best" alternative?  The article mentions a couple others.

Thoughts???

 - BS

Re: [Devil-Linux-discuss] [BULK] Devil on CF

[Frank W. <Fra...@ct...>]

On Monday 23 April 2007 04:52:22 Bruce E. Harris wrote:
> Hi,
>
> I am moving from an over powered, tricky firewall and going to give devil=
 a
> shot. Has anyone installed in on a bootable compact flash card? I don:t
> like moving devices (cd, floppy, hdd on my firewall if I can avoid them. I
> am considering a SBC with CF if I can get this to work.
>
> Best Regards,
>
> Bruce
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss

I use CF cards in 30+ devices. Works like a charm. Let me know if you need =
any=20
help. I have found that dd'ing to CF is much faster when you use a larger=20
blocksize (ie. bs=3D16M)

=46rank
=2D-=20
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 t=E9l.: +352 478-5973
 fax: +352 333797
 _______________________________________________

[Devil-Linux-discuss] Devil on CF

[Bruce E. H. <be...@sp...>]

Hi,

I am moving from an over powered, tricky firewall and going to give devil=
 a shot. Has anyone installed in on a bootable compact flash card? I don:=
t like moving devices (cd, floppy, hdd on my firewall if I can avoid them=
. I am considering a SBC with CF if I can get this to work.

Best Regards,

Bruce

Re: [Devil-Linux-discuss] Possible to make documentation on web site available for download?

[Heiko Z. <he...@zu...>]

On Sat, April 21, 2007 11:38, Bogdan Petrisor wrote:

> When you download the tar.gz with the iso file and you uncompress it you
> should find a docs folder. I think that's the same documentation as on the
> site.

Yes that's correct.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-Linux-discuss] Possible to make documentation on web site available for download?

[Ivan S. <is...@gm...>]

On 4/21/07, Lanny Marcus <mai...@co...> wrote:
> I can look at the documentation, online. I would like to download the
> documentation file, so I can read it and have it available for
> reference, for any configuration questions, on my desktop PC. This would
> help me and possibly help others interested in using D-L for a
> firewall/router. Thank you, for considering this! Lanny in Colombia

You can get it with:

wget -m -np http://www.devil-linux.org/documentation/1.2.x/

(or for whichever DL version you want it)

Re: [Devil-Linux-discuss] Possible to make documentation on web site available for download?

[Bogdan P. <pet...@ya...>]

Hello,

When you download the tar.gz with the iso file and you uncompress it you should find a docs
folder. I think that's the same documentation as on the site.

Best regards


--- Lanny Marcus <mai...@co...> wrote:

> Hello: I am a newbie to D-L. I will be using it for a brand new
> connection to ADSL (probably) or WiMAX (possibly), in the near future. I
> hope to have it configured correctly, when the new Internet connection
> is installed. On this page, http://www.devil-linux.org/support/docs.php
> I can look at the documentation, online. I would like to download the
> documentation file, so I can read it and have it available for
> reference, for any configuration questions, on my desktop PC. This would
> help me and possibly help others interested in using D-L for a
> firewall/router. Thank you, for considering this! Lanny in Colombia
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> 


--------------------------------
In the beginning there was nothing. Then, God said, "Let there be light". 
And there was still nothing, but at least you could see it.
--------------------------------

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Devil-Linux-discuss] Possible to make documentation on web site available for download?

[Lanny M. <mai...@co...>]

Hello: I am a newbie to D-L. I will be using it for a brand new
connection to ADSL (probably) or WiMAX (possibly), in the near future. I
hope to have it configured correctly, when the new Internet connection
is installed. On this page, http://www.devil-linux.org/support/docs.php
I can look at the documentation, online. I would like to download the
documentation file, so I can read it and have it available for
reference, for any configuration questions, on my desktop PC. This would
help me and possibly help others interested in using D-L for a
firewall/router. Thank you, for considering this! Lanny in Colombia

Re: [Devil-Linux-discuss] PPTP/GRE client not working, 1.2.13 RAID startup stucked

[Pekka K. <pek...@ja...>]

Heiko Zuerker kirjoitti:
> So I take it you didn't specify any modules for INITRD_MODULES in
> /etc/sysconfic/config ?
> The IDE drivers are compile into the kernel, SATA and SCSI have to be
> specifically loaded.
> It may be a kernel related problem.
> Not sure if a new Kernel will be out by the time we release 1.2.14
>
>   
No extra modules, it is a very basic setup. It gets stuck in when it 
scans for mdX, for raid I guess.
Too bad that I cannot easily test anymore, since these fw:s are out on 
other company offices now with 1.2.12.

>> Could it be possible to add some kind of setting to setup so that
>> harddisk related things could be skipped in startup? Or is this md/raid
>> module code fixed in next releases too?
>>     
>
> Actually I like the idea, so I added 2 new parameters to
> /etc/sysconfig/config, to disable the MD and LVM autostart.
>
>   

Well I think that would solve it, and it would speed up loading too. 
Thank you very much! Til' next release then... :-)

-Pekka

Re: [Devil-Linux-discuss] PPTP/GRE client not working, 1.2.13 RAID startup stucked

[Heiko Z. <he...@zu...>]

On Fri, April 20, 2007 06:31, Pekka Kilponen wrote:
> Ok,
>
> Thanks for quick reply.
>
>
> Using modprobe to ip_nat_proto_gre did the trick and pptp/gre client
> started working. In 1.2.14 release when shorewall/modules is editable I can
> also make this change permanent. Very good.
>
>
> The other thing is that in 1.2.13 with Intel 82801AA chipset devil-linux
> get's stucked when it is checking md volumes. in 1.2.12 this worked. I have
> no harddisks and no RAID hardware.

So I take it you didn't specify any modules for INITRD_MODULES in
/etc/sysconfic/config ?
The IDE drivers are compile into the kernel, SATA and SCSI have to be
specifically loaded.
It may be a kernel related problem.
Not sure if a new Kernel will be out by the time we release 1.2.14

> Could it be possible to add some kind of setting to setup so that
> harddisk related things could be skipped in startup? Or is this md/raid
> module code fixed in next releases too?

Actually I like the idea, so I added 2 new parameters to
/etc/sysconfig/config, to disable the MD and LVM autostart.

> Great firewall, been using this for two years now and I am currently
> taking it to all of our company's offices.

Thanks !

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-Linux-discuss] PPTP/GRE client not working, 1.2.13 RAID startup stucked

[Pekka K. <pek...@ja...>]

Ok,

Thanks for quick reply.

Using modprobe to ip_nat_proto_gre did the trick and pptp/gre client 
started working.
In 1.2.14 release when shorewall/modules is editable I can also make 
this change permanent.
Very good.

The other thing is that in 1.2.13 with Intel 82801AA chipset devil-linux 
get's stucked when it is checking md volumes.
in 1.2.12 this worked. I have no harddisks and no RAID hardware.

Could it be possible to add some kind of setting to setup so that 
harddisk related things could be skipped in startup?
Or is this md/raid module code fixed in next releases too?

Great firewall, been using this for two years now and I am currently 
taking it to all of our company's offices.

Brgs, Pekka

Heiko Zuerker kirjoitti:
> Hey,
>
> yes older releases of DL have problems with the iptables modules.
> This is going to be fixed in 1.2.14
> I also did a change to 1.2.14, which moves the
> /usr/share/shorewall/modules file to /etc/shorewall , so you can edit it.
>
> Heiko
>
> On Thu, April 19, 2007 09:18, Pekka Kilponen wrote:
>   
>> Hello!
>>
>>
>> PPTP/GRE client is not working inside NATted internal network. I am
>> using Devil-Linux 1.2.12 w/ Shorewall. I noticed that ip_nat_proto_gre
>> module is missing from /usr/share/shorewall/modules.
>> Is it needed? At least it is recommended by
>> http://www.shorewall.net/PPTP.htm#ClientsBehind .
>>
>>
>> How I can add this module to configuration, since
>> /usr/share/shorewall/modules is not inside /etc/, thus not being writable.
>>
>>
>> Cannot use 1.2.13, since raid module loading causes jam ( load order was
>> changed in 1.2.13 ) in my old Intel 82801AA mobo. (Not using harddisks)
>>
>>
>> Brgs,
>>
>>
>> Pekka
>>
>>
>> -------------------------------------------------------------------------
>>  This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Devil-linux-discuss mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>>
>>
>>     
>
>
>   


-- 

*Pekka Kilponen                    *
Systems Analyst
 
Mobile:    +358 - 41 - 502 0014
Fax:        +358 - 8 - 5545 664
Email:      pek...@ja... <mailto:pek...@ja...>
 
   
*Lunkintie 15, 90460 Oulunsalo, FINLAND*
               *www.jaicom.com*

/This message contains information that may be privileged or 
confidential and is the property of Jaicom Oy. It is intended only for 
the person to whom it is addressed. If you receive this message in 
error, please notify the sender immediately and delete all copies of 
this message./

Re: [Devil-Linux-discuss] Fwd: openvpn tun problem

[Heiko Z. <he...@zu...>]

On Thu, April 19, 2007 02:45, Jozsef Valkai wrote:
> Hi,
>
>
> We have devil-linux and starting the openvpn service I have got this
> error:
>
>
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> divert: not allocating divert_blk for non-ethernet device tun0
> divert: not allocating divert_blk for non-ethernet device tun1
> divert: not allocating divert_blk for non-ethernet device tun2
> divert: not allocating divert_blk for non-ethernet device tun3
> divert: not allocating divert_blk for non-ethernet device tun4
> divert: no divert_blk to free, tun4 not ethernet
> divert: no divert_blk to free, tun3 not ethernet
> divert: no divert_blk to free, tun2 not ethernet
> divert: no divert_blk to free, tun1 not ethernet
> divert: no divert_blk to free, tun0 not ethernet
>
> What is it? What should I do?

I'm not a 100% sure, but I think you can just ignore these messages.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11, Issue 2

[<ne...@co...>]

There really is no reason to NAT.

The way this box was intended to operate is as follows:
1)DHCP the clients (192.168.0.x)
2)Don't allow anything but telnet to a specific server (no dns etc...)
3)Do not trust the clients.

In a lot of ways the firewall is backwards.  Since we have embedded telnet clients (that can't be any smarter than they already are) we needed a way to lock down our wireless without interfering with the normal operation of the business.

I trust the network on the red side, but can't trust the wireless clients.  I'm not sure if it would help, but I have the freedom to have up to 255 IP's set aside on the network (red side).  Don't know if it would help to have the red interface have multiple IP's etc...

Aside from not being an expert on this, I have no reason to stick with NAT.  I'd be fine with modifying the config, but wouldn't know how to adjust it on my own.  Here's the relevant parts of the rules file.  Would it be as simple as dropping the DNAT and nat portions from the rules?

######################################################################
#accept DHCP
${IPTABLES} -A INPUT -p UDP -i eth1 --dport 67:68 -j ACCEPT
${IPTABLES} -A OUTPUT -p UDP -o eth1 --dport 67:68 -j ACCEPT

#translate to our network
${IPTABLES} -A PREROUTING -i eth1 -t nat -p TCP -d 10.10.10.18 -j DNAT --to $TELNETIP_NM

#allow access to the  server
${IPTABLES} -A FORWARD -i eth1 -p TCP -o eth0 -d $TELNETIP --dport 23 -j ACCEPT
${IPTABLES} -A FORWARD -i eth0 -p TCP -o eth1 -s $TELNETIP -m state --state ESTABLISHED,RELATED --sport 23 -j ACCEPT

#drop UDP packets
${IPTABLES} -A FORWARD -p UDP --dport 1: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport :21 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24:66 -j DROP
#${IPTABLES} -A INPUT -p TCP -i eth1 --dport 69: -j DROP
${IPTABLES} -A INPUT -p TCP -i eth1 --dport 24: -j DROP

#allow ping from WAN side only
${IPTABLES} -A INPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A OUTPUT -s $OUR_NW -p icmp -j ACCEPT
${IPTABLES} -A FORWARD -p icmp -j DROP
${IPTABLES} -A OUTPUT -p icmp -j DROP

######################################################################

# Masquerading (aka NAT, PAT, ...)
######################################################################
#${IPTABLES} -t nat -A POSTROUTING -o ${OUT_DEV} -j MASQUERADE
######################################################################

-joseph
 -------------- Original message ----------------------
From: dev...@li...
> Send Devil-linux-discuss mailing list submissions to
> 	dev...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> or, via email, send a message with subject or body 'help' to
> 	dev...@li...
> 
> You can reach the person managing the list at
> 	dev...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Devil-linux-discuss digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Devil-linux-discuss Digest, Vol 11,	Issue 1
>       (ne...@co...)
>    2. Re: Devil-linux-discuss Digest, Vol 11, Issue 1 (Heiko Zuerker)
>    3. Re: Devil-linux-discuss Digest, Vol 11,	Issue 1 (Fred Frigerio)
>    4. Re: ADSL not connecting - more details (David Nicol?s Abdala)
>    5. Re: ADSL not connecting - more details (Heiko Zuerker)
>    6. need of tcptraceroute on devil (Philippe Weill)
>    7. Fwd: openvpn tun problem (Jozsef Valkai)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Thu, 05 Apr 2007 19:19:33 +0000
> From: ne...@co...
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> 	Issue 1
> To: dev...@li...
> Message-ID:
> 	
> <040...@co...>
> 	
> 
> Heiko, thank you for your quick reply.
> 
> > What do you mean exactly with swapping sessions?
>  >I'm currently failing to understand where the DL box comes into play
>  >(except for the firewalling).
> 
> Swapping sessions:
> Each user logs into the telnet-based app.  
> When they log in, they get specific menu options based on their logon. 
> When one handheld "steals" a session, someone can power up a scanner and be 
> logged in as someone else--or be logged in as someone else who might have been 
> in the middle of an inventory transaction.  A good example of this might be 
> where one person was adding to an outbound shipment at the same time someone 
> else was receiving product.  Without warning the receiver's scanner was using 
> the shipper's session.  That really messes up the transactions and can take a 
> while to solve. 
> 
> 
> The DL box:
> This is how we are controlling the access to the network.  When we put the DL 
> box in, the dozen or so clients connecting to the telnet server all seem to be 
> coming from the same IP (the DL box).  Before the DL box, each of the scanners 
> had their own IP that could be seen by the telnet server.  This means that it 
> could restore a session if there was a disruption in our T1.  
> 
> Basically I'm looking for suggestions on how to keep the DL box in use without 
> (or at least minimizing) the problems with the telnet clients. The DL box has 
> prevented a number of people from hopping onto our wireless network and I'd like 
> to keep it.
> 
> -joseph
> 
> 
> > 
> > Message: 9
> > Date: Thu, 05 Apr 2007 18:49:45 +0000
> > From: ne...@co...
> > Subject: [Devil-Linux-discuss] Telnet clients swapping sessions
> > To: dev...@li...
> > Message-ID:
> > 	
> > <040...@co...>
> > 	
> > 
> > Good Day everyone,
> > 
> > I've set up a DL (1.2) server that controls wireless access to our LAN. It 
> runs 
> > on a via c3 system.
> > 
> > The only purpose for the wireless is to allow handheld barcode scanners (less 
> > than a dozen embedded DOS telnet clients) to connect to one of our servers. We 
> > set the firewall rules to only allow for specific telnet traffic and dhcp 
> > requests. 
> > 
> > All went fairly well for a couple of weeks.  Then we noticed that the embedded 
> > clients were swapping/stealing sessions.   Sometimes it would happen when 
> there 
> > was a glitch in our T1 etc...
> > 
> > Lately, things have gotten worse.  The handheld scanners are doing this 
> several 
> > times a day.   When one is powered on, for example, it sometimes steals the 
> > session from another handheld.  This is a problem as users have different 
> > permissions in the inventory software.  
> > 
> > If at all possible, the clients need to DHCP, and we need to keep the access 
> as 
> > tight as is possible.  Just going through the logs, I can see a dozen or two 
> > foiled attempts to hop onto our network.
> > 
> > 
> > I'll gladly provide more info since I don't know what info would help.
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 10
> > Date: Thu, 5 Apr 2007 14:01:25 -0500 (CDT)
> > From: "Heiko Zuerker" <he...@zu...>
> > Subject: Re: [Devil-Linux-discuss] Telnet clients swapping sessions
> > To: dev...@li...
> > Message-ID:
> > 	<295...@ga...>
> > Content-Type: text/plain;charset=iso-8859-1
> > 
> > 
> > On Thu, April 5, 2007 13:49, ne...@co... wrote:
> > > Good Day everyone,
> > >
> > >
> > > I've set up a DL (1.2) server that controls wireless access to our LAN.
> > > It runs on a via c3 system.
> > >
> > >
> > > The only purpose for the wireless is to allow handheld barcode scanners
> > > (less than a dozen embedded DOS telnet clients) to connect to one of our
> > > servers. We set the firewall rules to only allow for specific telnet
> > > traffic and dhcp requests.
> > >
> > > All went fairly well for a couple of weeks.  Then we noticed that the
> > > embedded clients were swapping/stealing sessions.   Sometimes it would
> > > happen when there was a glitch in our T1 etc...
> > >
> > > Lately, things have gotten worse.  The handheld scanners are doing this
> > > several times a day.   When one is powered on, for example, it sometimes
> > > steals the session from another handheld.  This is a problem as users
> > > have different permissions in the inventory software.
> > >
> > > If at all possible, the clients need to DHCP, and we need to keep the
> > > access as tight as is possible.  Just going through the logs, I can see a
> > > dozen or two foiled attempts to hop onto our network.
> > >
> > >
> > > I'll gladly provide more info since I don't know what info would help.
> > 
> > What do you mean exactly with swapping sessions?
> > I'm currently failing to understand where the DL box comes into play
> > (except for the firewalling).
> > 
> > -- 
> > 
> > Regards
> >   Heiko Zuerker
> >   http://www.devil-linux.org
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 5 Apr 2007 14:24:43 -0500 (CDT)
> From: "Heiko Zuerker" <he...@zu...>
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> 	Issue 1
> To: dev...@li...
> Message-ID:
> 	<272...@ga...>
> Content-Type: text/plain;charset=iso-8859-1
> 
> 
> On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > Heiko, thank you for your quick reply.
> >
> >
> >> What do you mean exactly with swapping sessions?
> >> I'm currently failing to understand where the DL box comes into play
> >> (except for the firewalling).
> >>
> >
> > Swapping sessions:
> > Each user logs into the telnet-based app.
> > When they log in, they get specific menu options based on their logon.
> > When one handheld "steals" a session, someone can power up a scanner and
> > be logged in as someone else--or be logged in as someone else who might
> > have been in the middle of an inventory transaction.  A good example of
> > this might be where one person was adding to an outbound shipment at the
> > same time someone else was receiving product.  Without warning the
> > receiver's scanner was using the shipper's session.  That really messes
> > up the transactions and can take a while to solve.
> >
> >
> > The DL box:
> > This is how we are controlling the access to the network.  When we put the
> > DL box in, the dozen or so clients connecting to the telnet server all
> > seem to be coming from the same IP (the DL box).  Before the DL box, each
> > of the scanners had their own IP that could be seen by the telnet server.
> > This means that it could restore a session if there was a disruption in
> > our T1.
> >
> > Basically I'm looking for suggestions on how to keep the DL box in use
> > without (or at least minimizing) the problems with the telnet clients.
> > The DL box has prevented a number of people from hopping onto our
> > wireless network and I'd like to keep it.
> 
> OK so you're currently hiding all the scanners behind a NAT right now.
> Would it be possible for you to 'officially' route the IPs from the
> scanners, without the NAT?
> 
> -- 
> 
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 5 Apr 2007 15:30:25 -0400
> From: "Fred Frigerio" <ffr...@lo...>
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> 	Issue 1
> To: <dev...@li...>
> Message-ID:
> 	<CB8...@wi...>
> Content-Type: text/plain;	charset="us-ascii"
> 
> It may sound obvious but you can DHCP and route one of the  non-internet
> routable networks. Either 192.168.x.x/24 or even partition 10.x.x.x./8
> into many /24 You can even superpose that IP network on another but then
> you would have to assign the IP's to a given MAC address on the DHCP
> server so you don't disturb your normal network. Another option is go
> the vlan way which is probably cleaner but may need an upgrade of the
> switches.
> 
> What is the reason to do NAT?
> 
> 
> Fred Frigerio
> Locust USA
>  
> This electronic message transmission contains information from Locust
> USA which may be confidential or privileged.  The information is
> intended to be for the use of the individual or entity named above.  If
> you are not the intended recipient, be aware that any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited.  If you have received this electronic transmission in error,
> please notify us by telephone (305-889-5410) or by reply via electronic
> mail immediately.
> 
> -----Original Message-----
> From: dev...@li...
> [mailto:dev...@li...] On Behalf Of
> Heiko Zuerker
> Sent: Thursday, April 05, 2007 3:25 PM
> To: dev...@li...
> Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
> Issue 1
> 
> 
> On Thu, April 5, 2007 14:19, ne...@co... wrote:
> > Heiko, thank you for your quick reply.
> >
> >
> >> What do you mean exactly with swapping sessions?
> >> I'm currently failing to understand where the DL box comes into play 
> >> (except for the firewalling).
> >>
> >
> > Swapping sessions:
> > Each user logs into the telnet-based app.
> > When they log in, they get specific menu options based on their logon.
> > When one handheld "steals" a session, someone can power up a scanner 
> > and be logged in as someone else--or be logged in as someone else who 
> > might have been in the middle of an inventory transaction.  A good 
> > example of this might be where one person was adding to an outbound 
> > shipment at the same time someone else was receiving product.  Without
> 
> > warning the receiver's scanner was using the shipper's session.  That 
> > really messes up the transactions and can take a while to solve.
> >
> >
> > The DL box:
> > This is how we are controlling the access to the network.  When we put
> 
> > the DL box in, the dozen or so clients connecting to the telnet server
> 
> > all seem to be coming from the same IP (the DL box).  Before the DL 
> > box, each of the scanners had their own IP that could be seen by the
> telnet server.
> > This means that it could restore a session if there was a disruption 
> > in our T1.
> >
> > Basically I'm looking for suggestions on how to keep the DL box in use
> 
> > without (or at least minimizing) the problems with the telnet clients.
> > The DL box has prevented a number of people from hopping onto our 
> > wireless network and I'd like to keep it.
> 
> OK so you're currently hiding all the scanners behind a NAT right now.
> Would it be possible for you to 'officially' route the IPs from the
> scanners, without the NAT?
> 
> -- 
> 
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
> 
> 
> 
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sat, 7 Apr 2007 14:52:39 -0300 (ART)
> From: David Nicol?s Abdala <dna...@ya...>
> Subject: Re: [Devil-Linux-discuss] ADSL not connecting - more details
> To: dev...@li...
> Message-ID: <137...@we...>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi,
> 
> I downloaded another distribution (CDRouter / www.wifi.com.ar) and
> following this distribution documentation I can connect to the internet
> with (mostly) no problems.
> When I reproduce the same steps with DL, nothing happends, it just
> Times Out.
> 
> The CDRouter distribution uses adsl-* scripts, instead of the pppoe-*.
> Can't tell if this is just a naming difference or is a different
> version of rp-pppoe.
> 
> To make the connection work I have to do:
> > ifconfig eth1 down
> > ifconfig eth1 up mtu 1500
> > adsl-start
> 
> after configuring adsl with adsl-setup.
> Following the same steps with DL does nothing. All modem lights are on,
> but doesn't connect.
> 
> Hope it lead you to te problem.
> Thanks.
> David.
> 
> 
> 	
> 
> 	
> 		
> __________________________________________________ 
> Pregunt?. Respond?. Descubr?. 
> Todo lo que quer?as saber, y lo que ni imaginabas, 
> est? en Yahoo! Respuestas (Beta). 
> ?Probalo ya! 
> http://www.yahoo.com.ar/respuestas 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Sun, 8 Apr 2007 10:02:33 -0500 (CDT)
> From: "Heiko Zuerker" <he...@zu...>
> Subject: Re: [Devil-Linux-discuss] ADSL not connecting - more details
> To: dev...@li...
> Message-ID:
> 	<494...@ww...>
> Content-Type: text/plain;charset=iso-8859-1
> 
> Hey,
> 
> this is the support forum for rp-pppoe: http://www.voy.com/41165/
> Did you read the docs in /usr/share/doc/rp-pppoe-3.8 ?
> 
> We're using the latest version of rp-pppoe (which is 3.8), that explains
> the differences.
> 
> Heiko
> 
> On Sat, April 7, 2007 12:52, David Nicol?s Abdala wrote:
> > Hi,
> >
> >
> > I downloaded another distribution (CDRouter / www.wifi.com.ar) and
> > following this distribution documentation I can connect to the internet
> > with (mostly) no problems. When I reproduce the same steps with DL,
> > nothing happends, it just Times Out.
> >
> >
> > The CDRouter distribution uses adsl-* scripts, instead of the pppoe-*.
> > Can't tell if this is just a naming difference or is a different
> > version of rp-pppoe.
> >
> > To make the connection work I have to do:
> >
> >> ifconfig eth1 down ifconfig eth1 up mtu 1500 adsl-start
> >
> > after configuring adsl with adsl-setup. Following the same steps with DL
> > does nothing. All modem lights are on, but doesn't connect.
> >
> > Hope it lead you to te problem.
> > Thanks.
> > David.
> >
> >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Pregunt?. Respond?. Descubr?.
> > Todo lo que quer?as saber, y lo que ni imaginabas,
> > est? en Yahoo! Respuestas (Beta). ?Probalo ya!
> > http://www.yahoo.com.ar/respuestas
> >
> >
> >
> > -------------------------------------------------------------------------
> >  Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >  _______________________________________________
> > Devil-linux-discuss mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> >
> >
> 
> 
> -- 
> 
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 16 Apr 2007 17:37:14 +0200
> From: Philippe Weill <Phi...@ae...>
> Subject: [Devil-Linux-discuss] need of tcptraceroute on devil
> To: dev...@li...
> Message-ID: <462...@ae...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Could be a good product to include in devil-linux
>   http://michael.toren.net/code/tcptraceroute/
> 
> Thanks in advance
> -- 
>   Weill Philippe -  Administrateur Systeme et Reseaux
>   CNRS Service Aeronomie - Universite Pierre et Marie Curie -
> 
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Thu, 19 Apr 2007 09:45:30 +0200
> From: "Jozsef Valkai" <jv...@gm...>
> Subject: [Devil-Linux-discuss] Fwd: openvpn tun problem
> To: dev...@li...
> Message-ID:
> 	<1b5...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi,
> 
> We have devil-linux and starting the openvpn service I have got this error:
> 
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> divert: not allocating divert_blk for non-ethernet device tun0
> divert: not allocating divert_blk for non-ethernet device tun1
> divert: not allocating divert_blk for non-ethernet device tun2
> divert: not allocating divert_blk for non-ethernet device tun3
> divert: not allocating divert_blk for non-ethernet device tun4
> divert: no divert_blk to free, tun4 not ethernet
> divert: no divert_blk to free, tun3 not ethernet
> divert: no divert_blk to free, tun2 not ethernet
> divert: no divert_blk to free, tun1 not ethernet
> divert: no divert_blk to free, tun0 not ethernet
> 
> 
> What is it? What should I do?
> 
> Thanks.
> --
> Valkai Jozsef
> +36 70 36 28 147
> va...@ex...
> jv...@gm...
> lat:  +47? 30' 43.94"
> lon: +19? 9' 9.39"
> 
> 
> 
> ------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 
> ------------------------------
> 
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> 
> 
> End of Devil-linux-discuss Digest, Vol 11, Issue 2
> **************************************************

Re: [Devil-Linux-discuss] PPTP/GRE client not working

[Heiko Z. <he...@zu...>]

Hey,

yes older releases of DL have problems with the iptables modules.
This is going to be fixed in 1.2.14
I also did a change to 1.2.14, which moves the
/usr/share/shorewall/modules file to /etc/shorewall , so you can edit it.

Heiko

On Thu, April 19, 2007 09:18, Pekka Kilponen wrote:
> Hello!
>
>
> PPTP/GRE client is not working inside NATted internal network. I am
> using Devil-Linux 1.2.12 w/ Shorewall. I noticed that ip_nat_proto_gre
> module is missing from /usr/share/shorewall/modules.
> Is it needed? At least it is recommended by
> http://www.shorewall.net/PPTP.htm#ClientsBehind .
>
>
> How I can add this module to configuration, since
> /usr/share/shorewall/modules is not inside /etc/, thus not being writable.
>
>
> Cannot use 1.2.13, since raid module loading causes jam ( load order was
> changed in 1.2.13 ) in my old Intel 82801AA mobo. (Not using harddisks)
>
>
> Brgs,
>
>
> Pekka
>
>
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>
>


-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-Linux-discuss] PPTP/GRE client not working

[Pekka K. <pek...@ja...>]

Hello!

PPTP/GRE client is not working inside NATted internal network. I am 
using Devil-Linux 1.2.12 w/ Shorewall.
I noticed that ip_nat_proto_gre module is missing from 
/usr/share/shorewall/modules.
Is it needed? At least it is recommended by 
http://www.shorewall.net/PPTP.htm#ClientsBehind .

How I can add this module to configuration, since 
/usr/share/shorewall/modules is not inside /etc/, thus not being writable.

Cannot use 1.2.13, since raid module loading causes jam ( load order was 
changed in 1.2.13 ) in my old Intel 82801AA mobo.
(Not using harddisks)

Brgs,

Pekka

[Devil-Linux-discuss] Fwd: openvpn tun problem

[Jozsef V. <jv...@gm...>]

Hi,

We have devil-linux and starting the openvpn service I have got this error:

Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
divert: not allocating divert_blk for non-ethernet device tun0
divert: not allocating divert_blk for non-ethernet device tun1
divert: not allocating divert_blk for non-ethernet device tun2
divert: not allocating divert_blk for non-ethernet device tun3
divert: not allocating divert_blk for non-ethernet device tun4
divert: no divert_blk to free, tun4 not ethernet
divert: no divert_blk to free, tun3 not ethernet
divert: no divert_blk to free, tun2 not ethernet
divert: no divert_blk to free, tun1 not ethernet
divert: no divert_blk to free, tun0 not ethernet


What is it? What should I do?

Thanks.
--
Valkai Jozsef
+36 70 36 28 147
va...@ex...
jv...@gm...
lat:  +47=B0 30' 43.94"
lon: +19=B0 9' 9.39"

[Devil-Linux-discuss] need of tcptraceroute on devil

[Philippe W. <Phi...@ae...>]

Could be a good product to include in devil-linux
  http://michael.toren.net/code/tcptraceroute/

Thanks in advance
-- 
  Weill Philippe -  Administrateur Systeme et Reseaux
  CNRS Service Aeronomie - Universite Pierre et Marie Curie -

Re: [Devil-Linux-discuss] ADSL not connecting - more details

[Heiko Z. <he...@zu...>]

Hey,

this is the support forum for rp-pppoe: http://www.voy.com/41165/
Did you read the docs in /usr/share/doc/rp-pppoe-3.8 ?

We're using the latest version of rp-pppoe (which is 3.8), that explains
the differences.

Heiko

On Sat, April 7, 2007 12:52, David Nicolás Abdala wrote:
> Hi,
>
>
> I downloaded another distribution (CDRouter / www.wifi.com.ar) and
> following this distribution documentation I can connect to the internet
> with (mostly) no problems. When I reproduce the same steps with DL,
> nothing happends, it just Times Out.
>
>
> The CDRouter distribution uses adsl-* scripts, instead of the pppoe-*.
> Can't tell if this is just a naming difference or is a different
> version of rp-pppoe.
>
> To make the connection work I have to do:
>
>> ifconfig eth1 down ifconfig eth1 up mtu 1500 adsl-start
>
> after configuring adsl with adsl-setup. Following the same steps with DL
> does nothing. All modem lights are on, but doesn't connect.
>
> Hope it lead you to te problem.
> Thanks.
> David.
>
>
>
>
>
>
>
> __________________________________________________
> Preguntá. Respondé. Descubrí.
> Todo lo que querías saber, y lo que ni imaginabas,
> está en Yahoo! Respuestas (Beta). ¡Probalo ya!
> http://www.yahoo.com.ar/respuestas
>
>
>
> -------------------------------------------------------------------------
>  Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>  _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
>
>


-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-Linux-discuss] ADSL not connecting - more details

[<dna...@ya...>]

Hi,

I downloaded another distribution (CDRouter / www.wifi.com.ar) and
following this distribution documentation I can connect to the internet
with (mostly) no problems.
When I reproduce the same steps with DL, nothing happends, it just
Times Out.

The CDRouter distribution uses adsl-* scripts, instead of the pppoe-*.
Can't tell if this is just a naming difference or is a different
version of rp-pppoe.

To make the connection work I have to do:
> ifconfig eth1 down
> ifconfig eth1 up mtu 1500
> adsl-start

after configuring adsl with adsl-setup.
Following the same steps with DL does nothing. All modem lights are on,
but doesn't connect.

Hope it lead you to te problem.
Thanks.
David.


	

	
		
__________________________________________________ 
Preguntá. Respondé. Descubrí. 
Todo lo que querías saber, y lo que ni imaginabas, 
está en Yahoo! Respuestas (Beta). 
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas 

Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11, Issue 1

[Fred F. <ffr...@lo...>]

It may sound obvious but you can DHCP and route one of the  non-internet
routable networks. Either 192.168.x.x/24 or even partition 10.x.x.x./8
into many /24 You can even superpose that IP network on another but then
you would have to assign the IP's to a given MAC address on the DHCP
server so you don't disturb your normal network. Another option is go
the vlan way which is probably cleaner but may need an upgrade of the
switches.

What is the reason to do NAT?


Fred Frigerio
Locust USA
=20
This electronic message transmission contains information from Locust
USA which may be confidential or privileged.  The information is
intended to be for the use of the individual or entity named above.  If
you are not the intended recipient, be aware that any disclosure,
copying, distribution or use of the contents of this information is
prohibited.  If you have received this electronic transmission in error,
please notify us by telephone (305-889-5410) or by reply via electronic
mail immediately.

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of
Heiko Zuerker
Sent: Thursday, April 05, 2007 3:25 PM
To: dev...@li...
Subject: Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11,
Issue 1


On Thu, April 5, 2007 14:19, ne...@co... wrote:
> Heiko, thank you for your quick reply.
>
>
>> What do you mean exactly with swapping sessions?
>> I'm currently failing to understand where the DL box comes into play=20
>> (except for the firewalling).
>>
>
> Swapping sessions:
> Each user logs into the telnet-based app.
> When they log in, they get specific menu options based on their logon.
> When one handheld "steals" a session, someone can power up a scanner=20
> and be logged in as someone else--or be logged in as someone else who=20
> might have been in the middle of an inventory transaction.  A good=20
> example of this might be where one person was adding to an outbound=20
> shipment at the same time someone else was receiving product.  Without

> warning the receiver's scanner was using the shipper's session.  That=20
> really messes up the transactions and can take a while to solve.
>
>
> The DL box:
> This is how we are controlling the access to the network.  When we put

> the DL box in, the dozen or so clients connecting to the telnet server

> all seem to be coming from the same IP (the DL box).  Before the DL=20
> box, each of the scanners had their own IP that could be seen by the
telnet server.
> This means that it could restore a session if there was a disruption=20
> in our T1.
>
> Basically I'm looking for suggestions on how to keep the DL box in use

> without (or at least minimizing) the problems with the telnet clients.
> The DL box has prevented a number of people from hopping onto our=20
> wireless network and I'd like to keep it.

OK so you're currently hiding all the scanners behind a NAT right now.
Would it be possible for you to 'officially' route the IPs from the
scanners, without the NAT?

--=20

Regards
  Heiko Zuerker
  http://www.devil-linux.org



------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Devil-linux-discuss mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss

Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11, Issue 1

[Heiko Z. <he...@zu...>]

On Thu, April 5, 2007 14:19, ne...@co... wrote:
> Heiko, thank you for your quick reply.
>
>
>> What do you mean exactly with swapping sessions?
>> I'm currently failing to understand where the DL box comes into play
>> (except for the firewalling).
>>
>
> Swapping sessions:
> Each user logs into the telnet-based app.
> When they log in, they get specific menu options based on their logon.
> When one handheld "steals" a session, someone can power up a scanner and
> be logged in as someone else--or be logged in as someone else who might
> have been in the middle of an inventory transaction.  A good example of
> this might be where one person was adding to an outbound shipment at the
> same time someone else was receiving product.  Without warning the
> receiver's scanner was using the shipper's session.  That really messes
> up the transactions and can take a while to solve.
>
>
> The DL box:
> This is how we are controlling the access to the network.  When we put the
> DL box in, the dozen or so clients connecting to the telnet server all
> seem to be coming from the same IP (the DL box).  Before the DL box, each
> of the scanners had their own IP that could be seen by the telnet server.
> This means that it could restore a session if there was a disruption in
> our T1.
>
> Basically I'm looking for suggestions on how to keep the DL box in use
> without (or at least minimizing) the problems with the telnet clients.
> The DL box has prevented a number of people from hopping onto our
> wireless network and I'd like to keep it.

OK so you're currently hiding all the scanners behind a NAT right now.
Would it be possible for you to 'officially' route the IPs from the
scanners, without the NAT?

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-Linux-discuss] Devil-linux-discuss Digest, Vol 11, Issue 1

[<ne...@co...>]

Heiko, thank you for your quick reply.

> What do you mean exactly with swapping sessions?
 >I'm currently failing to understand where the DL box comes into play
 >(except for the firewalling).

Swapping sessions:
Each user logs into the telnet-based app.  
When they log in, they get specific menu options based on their logon. 
When one handheld "steals" a session, someone can power up a scanner and be logged in as someone else--or be logged in as someone else who might have been in the middle of an inventory transaction.  A good example of this might be where one person was adding to an outbound shipment at the same time someone else was receiving product.  Without warning the receiver's scanner was using the shipper's session.  That really messes up the transactions and can take a while to solve. 


The DL box:
This is how we are controlling the access to the network.  When we put the DL box in, the dozen or so clients connecting to the telnet server all seem to be coming from the same IP (the DL box).  Before the DL box, each of the scanners had their own IP that could be seen by the telnet server.  This means that it could restore a session if there was a disruption in our T1.  

Basically I'm looking for suggestions on how to keep the DL box in use without (or at least minimizing) the problems with the telnet clients. The DL box has prevented a number of people from hopping onto our wireless network and I'd like to keep it.

-joseph


> 
> Message: 9
> Date: Thu, 05 Apr 2007 18:49:45 +0000
> From: ne...@co...
> Subject: [Devil-Linux-discuss] Telnet clients swapping sessions
> To: dev...@li...
> Message-ID:
> 	
> <040...@co...>
> 	
> 
> Good Day everyone,
> 
> I've set up a DL (1.2) server that controls wireless access to our LAN. It runs 
> on a via c3 system.
> 
> The only purpose for the wireless is to allow handheld barcode scanners (less 
> than a dozen embedded DOS telnet clients) to connect to one of our servers. We 
> set the firewall rules to only allow for specific telnet traffic and dhcp 
> requests. 
> 
> All went fairly well for a couple of weeks.  Then we noticed that the embedded 
> clients were swapping/stealing sessions.   Sometimes it would happen when there 
> was a glitch in our T1 etc...
> 
> Lately, things have gotten worse.  The handheld scanners are doing this several 
> times a day.   When one is powered on, for example, it sometimes steals the 
> session from another handheld.  This is a problem as users have different 
> permissions in the inventory software.  
> 
> If at all possible, the clients need to DHCP, and we need to keep the access as 
> tight as is possible.  Just going through the logs, I can see a dozen or two 
> foiled attempts to hop onto our network.
> 
> 
> I'll gladly provide more info since I don't know what info would help.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Thu, 5 Apr 2007 14:01:25 -0500 (CDT)
> From: "Heiko Zuerker" <he...@zu...>
> Subject: Re: [Devil-Linux-discuss] Telnet clients swapping sessions
> To: dev...@li...
> Message-ID:
> 	<295...@ga...>
> Content-Type: text/plain;charset=iso-8859-1
> 
> 
> On Thu, April 5, 2007 13:49, ne...@co... wrote:
> > Good Day everyone,
> >
> >
> > I've set up a DL (1.2) server that controls wireless access to our LAN.
> > It runs on a via c3 system.
> >
> >
> > The only purpose for the wireless is to allow handheld barcode scanners
> > (less than a dozen embedded DOS telnet clients) to connect to one of our
> > servers. We set the firewall rules to only allow for specific telnet
> > traffic and dhcp requests.
> >
> > All went fairly well for a couple of weeks.  Then we noticed that the
> > embedded clients were swapping/stealing sessions.   Sometimes it would
> > happen when there was a glitch in our T1 etc...
> >
> > Lately, things have gotten worse.  The handheld scanners are doing this
> > several times a day.   When one is powered on, for example, it sometimes
> > steals the session from another handheld.  This is a problem as users
> > have different permissions in the inventory software.
> >
> > If at all possible, the clients need to DHCP, and we need to keep the
> > access as tight as is possible.  Just going through the logs, I can see a
> > dozen or two foiled attempts to hop onto our network.
> >
> >
> > I'll gladly provide more info since I don't know what info would help.
> 
> What do you mean exactly with swapping sessions?
> I'm currently failing to understand where the DL box comes into play
> (except for the firewalling).
> 
> -- 
> 
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
> 
> 
> 
> 
> 

Re: [Devil-Linux-discuss] Telnet clients swapping sessions

[Heiko Z. <he...@zu...>]

On Thu, April 5, 2007 13:49, ne...@co... wrote:
> Good Day everyone,
>
>
> I've set up a DL (1.2) server that controls wireless access to our LAN.
> It runs on a via c3 system.
>
>
> The only purpose for the wireless is to allow handheld barcode scanners
> (less than a dozen embedded DOS telnet clients) to connect to one of our
> servers. We set the firewall rules to only allow for specific telnet
> traffic and dhcp requests.
>
> All went fairly well for a couple of weeks.  Then we noticed that the
> embedded clients were swapping/stealing sessions.   Sometimes it would
> happen when there was a glitch in our T1 etc...
>
> Lately, things have gotten worse.  The handheld scanners are doing this
> several times a day.   When one is powered on, for example, it sometimes
> steals the session from another handheld.  This is a problem as users
> have different permissions in the inventory software.
>
> If at all possible, the clients need to DHCP, and we need to keep the
> access as tight as is possible.  Just going through the logs, I can see a
> dozen or two foiled attempts to hop onto our network.
>
>
> I'll gladly provide more info since I don't know what info would help.

What do you mean exactly with swapping sessions?
I'm currently failing to understand where the DL box comes into play
(except for the firewalling).

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-Linux-discuss] Telnet clients swapping sessions

[<ne...@co...>]

Good Day everyone,

I've set up a DL (1.2) server that controls wireless access to our LAN. It runs on a via c3 system.

The only purpose for the wireless is to allow handheld barcode scanners (less than a dozen embedded DOS telnet clients) to connect to one of our servers. We set the firewall rules to only allow for specific telnet traffic and dhcp requests. 

All went fairly well for a couple of weeks.  Then we noticed that the embedded clients were swapping/stealing sessions.   Sometimes it would happen when there was a glitch in our T1 etc...

Lately, things have gotten worse.  The handheld scanners are doing this several times a day.   When one is powered on, for example, it sometimes steals the session from another handheld.  This is a problem as users have different permissions in the inventory software.  

If at all possible, the clients need to DHCP, and we need to keep the access as tight as is possible.  Just going through the logs, I can see a dozen or two foiled attempts to hop onto our network.


I'll gladly provide more info since I don't know what info would help.