Not forwarding?

Not forwarding?

[Cody Harris]

Here's my setup:
My filewall has eth0 and eth1. 0 is ethe net and 1 is my ssh box. This is my firewall setup:


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Not forwarding?

[Cody Harris]

Here's my setup:
My filewall has eth0 and eth1. 0 is ethe net and 1 is my ssh box. Eth0 is 10.30.7.147 and Eth1 is 192.168.0.1...Eth1 is connected to Eth0 on the other box...192.168.0.2.

We have found out ssh isn't forwarding properly. What's the deal?

This is my firewall setup:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  anywhere             anywhere           tcp dpt:10000
DROP       tcp  --  anywhere             anywhere           tcp dpt:631
DROP       tcp  --  anywhere             anywhere           tcp dpt:http
DROP       tcp  --  anywhere             anywhere           tcp dpt:smtp
DROP       tcp  --  anywhere             anywhere           tcp dpt:ftp
ACCEPT     icmp --  anywhere             anywhere           icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere           icmp destination-unreachable
ACCEPT     icmp --  anywhere             anywhere           icmp redirect
ACCEPT     icmp --  anywhere             anywhere           icmp echo-request
ACCEPT     icmp --  anywhere             anywhere           icmp time-exceeded
DROP       icmp --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere           icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere           icmp destination-unreachable
ACCEPT     icmp --  anywhere             anywhere           icmp redirect
ACCEPT     icmp --  anywhere             anywhere           icmp echo-request
ACCEPT     icmp --  anywhere             anywhere           icmp time-exceeded
ACCEPT     tcp  --  anywhere             192.168.0.2        tcp dpt:ssh

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

We have noticed that ssh isn't getting forwarded. What's wrong?

-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[David Cannings]

On Sunday 28 March 2004 20:52, Cody Harris wrote:
> This is my firewall setup:
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     icmp --  anywhere             anywhere           icmp
> echo-reply ACCEPT     icmp --  anywhere             anywhere          
> icmp destination-unreachable ACCEPT     icmp --  anywhere            
> anywhere           icmp redirect ACCEPT     icmp --  anywhere          
>   anywhere           icmp echo-request ACCEPT     icmp --  anywhere    
>         anywhere           icmp time-exceeded ACCEPT     tcp  -- 
> anywhere             192.168.0.2        tcp dpt:ssh
> We have noticed that ssh isn't getting forwarded. What's wrong?

What about the replies from SSH which will come from source port 22?  
Either add a rule to explicitly allow from sport ssh or add an 
ESTABLISHED/RELATED rule in there.

David

Re: Not forwarding?

[Antony Stone]

On Sunday 28 March 2004 8:52 pm, Cody Harris wrote:

> Here's my setup:
> My filewall has eth0 and eth1. 0 is ethe net and 1 is my ssh box. Eth0 is
> 10.30.7.147 and Eth1 is 192.168.0.1...Eth1 is connected to Eth0 on the
> other box...192.168.0.2.
>
> We have found out ssh isn't forwarding properly. What's the deal?

1. Is any other protocol being forwarded correctly?

2. What does "cat /proc/sys/net/ipv4/ip_forward" return?

3. What do you mean by "properly"?   Does ssh work at all?  Sometimes?   From 
some machines?   Only for a certain time, then stops?   What?

> This is my firewall setup:
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere
> ACCEPT     icmp --  anywhere             anywhere           icmp echo-reply
> ACCEPT     icmp --  anywhere             anywhere           icmp
> destination-unreachable ACCEPT     icmp --  anywhere             anywhere  
>         icmp redirect ACCEPT     icmp --  anywhere             anywhere    
>       icmp echo-request ACCEPT     icmp --  anywhere             anywhere  
>         icmp time-exceeded ACCEPT     tcp  --  anywhere            
> 192.168.0.2        tcp dpt:ssh

4. Sorry for the way my mailer has mangled your rules, however please post the 
output from "iptables -L FORWARD -nvx" (the v is important as it shows the 
interface data which is not in the standard listing output).

5. How are you testing the setup?

Regards,

Antony.

-- 
If at first you don't succeed, destroy all the evidence that you tried.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Antony Stone]

On Sunday 28 March 2004 9:43 pm, David Cannings wrote:

> On Sunday 28 March 2004 20:52, Cody Harris wrote:
> > This is my firewall setup:
> > Chain FORWARD (policy ACCEPT)
> > target     prot opt source               destination
> > ACCEPT     all  --  anywhere             anywhere
> > ACCEPT     icmp --  anywhere             anywhere           icmp
> > echo-reply ACCEPT     icmp --  anywhere             anywhere
> > icmp destination-unreachable ACCEPT     icmp --  anywhere
> > anywhere           icmp redirect ACCEPT     icmp --  anywhere
> >   anywhere           icmp echo-request ACCEPT     icmp --  anywhere
> >         anywhere           icmp time-exceeded ACCEPT     tcp  --
> > anywhere             192.168.0.2        tcp dpt:ssh
> > We have noticed that ssh isn't getting forwarded. What's wrong?
>
> What about the replies from SSH which will come from source port 22?
> Either add a rule to explicitly allow from sport ssh or add an
> ESTABLISHED/RELATED rule in there.

That might be covered by the first rule:

> > ACCEPT     all  --  anywhere             anywhere

We won't know until we see the output of a listing with -v to show us the 
interfaces too.

However your point about there being no ESTABLISHED,RELATED rule is a good one 
- it suggests that netfilter is not being used statefully, which means it is 
very difficult to make the system (a) work and (b) secure at the same time.

Regards,

Antony.

-- 
Wanted: telepath.   You know where to apply.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Cody Harris]

On Sun, 28 Mar 2004 21:48:46 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Sunday 28 March 2004 8:52 pm, Cody Harris wrote:
> 
> > Here's my setup:
> > My filewall has eth0 and eth1. 0 is ethe net and 1 is my ssh box. Eth0 is
> > 10.30.7.147 and Eth1 is 192.168.0.1...Eth1 is connected to Eth0 on the
> > other box...192.168.0.2.
> >
> > We have found out ssh isn't forwarding properly. What's the deal?
> 
> 1. Is any other protocol being forwarded correctly?

I'm only forwarding tcp, i don't know what the deal is with ICMP.

> 
> 2. What does "cat /proc/sys/net/ipv4/ip_forward" return?

1

> 
> 3. What do you mean by "properly"?   Does ssh work at all?  Sometimes?   From 
> some machines?   Only for a certain time, then stops?   What?

It logs into my firewall. We've tested that by creating "phoneyuser" on the firewall and logging in as that.

> 
> > This is my firewall setup:
> >
> > Chain FORWARD (policy ACCEPT)
> > target     prot opt source               destination
> > ACCEPT     all  --  anywhere             anywhere
> > ACCEPT     icmp --  anywhere             anywhere           icmp echo-reply
> > ACCEPT     icmp --  anywhere             anywhere           icmp
> > destination-unreachable ACCEPT     icmp --  anywhere             anywhere  
> >         icmp redirect ACCEPT     icmp --  anywhere             anywhere    
> >       icmp echo-request ACCEPT     icmp --  anywhere             anywhere  
> >         icmp time-exceeded ACCEPT     tcp  --  anywhere            
> > 192.168.0.2        tcp dpt:ssh
> 
> 4. Sorry for the way my mailer has mangled your rules, however please post the 
> output from "iptables -L FORWARD -nvx" (the v is important as it shows the 
> interface data which is not in the standard listing output).
> 
> 5. How are you testing the setup?
> 
> Regards,
> 
> Antony.
> 
> -- 
> If at first you don't succeed, destroy all the evidence that you tried.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Cody Harris]

I rewrote the rules following your suggestions. It still doesn't work:

Chain INPUT (policy ACCEPT 300 packets, 77689 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:10000
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:631
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:http
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:smtp
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:ftp
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-reply
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp destination-unreachable
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp redirect
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-request
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp time-exceeded
    0     0 DROP       icmp --  eth0   any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  eth1   any     anywhere             anywhere
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere           icmp echo-reply
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere           icmp destination-unreachable
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere           icmp redirect
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere           icmp echo-request
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere           icmp time-exceeded
    0     0 ACCEPT     tcp  --  any    any     anywhere             192.168.0.2        tcp dpt:ssh state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 301 packets, 66019 bytes)
 pkts bytes target     prot opt in     out     source               destination


On Sun, 28 Mar 2004 21:54:17 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Sunday 28 March 2004 9:43 pm, David Cannings wrote:
> 
> > On Sunday 28 March 2004 20:52, Cody Harris wrote:
> > > This is my firewall setup:
> > > Chain FORWARD (policy ACCEPT)
> > > target     prot opt source               destination
> > > ACCEPT     all  --  anywhere             anywhere
> > > ACCEPT     icmp --  anywhere             anywhere           icmp
> > > echo-reply ACCEPT     icmp --  anywhere             anywhere
> > > icmp destination-unreachable ACCEPT     icmp --  anywhere
> > > anywhere           icmp redirect ACCEPT     icmp --  anywhere
> > >   anywhere           icmp echo-request ACCEPT     icmp --  anywhere
> > >         anywhere           icmp time-exceeded ACCEPT     tcp  --
> > > anywhere             192.168.0.2        tcp dpt:ssh
> > > We have noticed that ssh isn't getting forwarded. What's wrong?
> >
> > What about the replies from SSH which will come from source port 22?
> > Either add a rule to explicitly allow from sport ssh or add an
> > ESTABLISHED/RELATED rule in there.
> 
> That might be covered by the first rule:
> 
> > > ACCEPT     all  --  anywhere             anywhere
> 
> We won't know until we see the output of a listing with -v to show us the 
> interfaces too.
> 
> However your point about there being no ESTABLISHED,RELATED rule is a good one 
> - it suggests that netfilter is not being used statefully, which means it is 
> very difficult to make the system (a) work and (b) secure at the same time.
> 
> Regards,
> 
> Antony.
> 
> -- 
> Wanted: telepath.   You know where to apply.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Antony Stone]

On Sunday 28 March 2004 9:59 pm, Cody Harris wrote:

> On Sun, 28 Mar 2004 21:48:46 Antony Stone wrote:
> >
> > 1. Is any other protocol being forwarded correctly?
>
> I'm only forwarding tcp, i don't know what the deal is with ICMP.

Yes, I meant any protocol like HTTP, SMTP, POP3....?

Another way of wording my question: "Is SSH failing where other things work, 
or is SSH failing the same as everything else?"

> > 2. What does "cat /proc/sys/net/ipv4/ip_forward" return?
>
> 1

That's good.

> > 3. What do you mean by "properly"?   Does ssh work at all?  Sometimes?  
> > From some machines?   Only for a certain time, then stops?   What?
>
> It logs into my firewall. We've tested that by creating "phoneyuser" on the
> firewall and logging in as that.

So what's the answer to question 5?

> > 4. Sorry for the way my mailer has mangled your rules, however please
> > post the output from "iptables -L FORWARD -nvx" (the v is important as it
> > shows the interface data which is not in the standard listing output).
> >
> > 5. How are you testing the setup?

Regards,

Antony.

-- 
The difference between theory and practice is that in theory there is no 
difference, whereas in practice there is.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[David Cannings]

On Sunday 28 March 2004 21:59, Cody Harris wrote:
> On Sun, 28 Mar 2004 21:48:46 +0100,
> Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
> > 1. Is any other protocol being forwarded correctly?
> I'm only forwarding tcp, i don't know what the deal is with ICMP.

What about other application level protocols, such as HTTP, FTP or IMAP?  
Note that you should try to connect to something other than your 
netfilter machine, for the reasons described below.

> > 2. What does "cat /proc/sys/net/ipv4/ip_forward" return?
> 1

This is fine.

> > 3. What do you mean by "properly"?   Does ssh work at all? 
> > Sometimes?   From some machines?   Only for a certain time, then
> > stops?   What?
> It logs into my firewall. We've tested that by creating "phoneyuser" on
> the firewall and logging in as that.

You can log in to the firewall because your INPUT chain has a default 
ACCEPT policy and you don't drop packets coming in on 22.  Can you 
connect to SSH servers on the other side of the netfilter machine?  This 
is where the FORWARD chain comes into action.

As an aside, note that creating "phoneyuser" doesn't really test netfilter 
at all.  You either can or can't connect to the port, netfilter wont stop 
any specific user from logging in.

As Anthony asked, please paste at least your FORWARD chain using the -v 
switch to iptables so we can see the counters.

David

Re: Not forwarding?

[Cody Harris]

On Sun, 28 Mar 2004 21:48:46 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
> 4. Sorry for the way my mailer has mangled your rules, however please post the 
> output from "iptables -L FORWARD -nvx" (the v is important as it shows the 
> interface data which is not in the standard listing output).

I did that. Check the other thread. Unless you want me to repost.

> 
> 5. How are you testing the setup?

I created 2 unique usernames. And tested both. I got a freiend to try both. Phoneyuser on the firewall and night on the box i wanted. night didn't work but phoneyuser logged in ok

> 
> Regards,
> 
> Antony.
> 
> -- 
> If at first you don't succeed, destroy all the evidence that you tried.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[David Cannings]

On Sunday 28 March 2004 22:07, Cody Harris wrote:
> I rewrote the rules following your suggestions. It still doesn't work:
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> any    any     anywhere             192.168.0.2        tcp dpt:ssh
> state RELATED,ESTABLISHED

What I meant want a separate rule in FORWARD for established or related 
packets.  However, please see the other mail I have just sent.

David

Re: Not forwarding?

[Cody Harris]

On Sun, 28 Mar 2004 22:09:16 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Sunday 28 March 2004 9:59 pm, Cody Harris wrote:
> 
> > On Sun, 28 Mar 2004 21:48:46 Antony Stone wrote:
> > >
> > > 1. Is any other protocol being forwarded correctly?
> >
> > I'm only forwarding tcp, i don't know what the deal is with ICMP.
> 
> Yes, I meant any protocol like HTTP, SMTP, POP3....?
> 
> Another way of wording my question: "Is SSH failing where other things work, 
> or is SSH failing the same as everything else?"

I'll try using HTTP. I'll post the results.

> 
> > > 2. What does "cat /proc/sys/net/ipv4/ip_forward" return?
> >
> > 1
> 
> That's good.
> 
> > > 3. What do you mean by "properly"?   Does ssh work at all?  Sometimes?  
> > > From some machines?   Only for a certain time, then stops?   What?
> >
> > It logs into my firewall. We've tested that by creating "phoneyuser" on the
> > firewall and logging in as that.
> 
> So what's the answer to question 5?

I'm another e-mail.

> 
> > > 4. Sorry for the way my mailer has mangled your rules, however please
> > > post the output from "iptables -L FORWARD -nvx" (the v is important as it
> > > shows the interface data which is not in the standard listing output).
> > >
> > > 5. How are you testing the setup?
> 
> Regards,
> 
> Antony.
> 
> -- 
> The difference between theory and practice is that in theory there is no 
> difference, whereas in practice there is.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Antony Stone]

On Sunday 28 March 2004 10:07 pm, Cody Harris wrote:

> I rewrote the rules following your suggestions. It still doesn't work:
>
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> target     prot opt in     out     source              destination
> ACCEPT     all  --  eth1   any     anywhere             anywhere

Okay, that will allow all packets coming through from eth1

> ACCEPT     tcp  --  any    any     anywhere             192.168.0.2       
> tcp dpt:ssh state RELATED,ESTABLISHED

That will allow packets coming through from 192.168.0.2 (which is plugged in 
to eth1) to destination port 22.

You have no rule to allow the reply packets back (and the above rule won't 
allow the NEW packets through, either).

Try this:

iptables -F FORWARD
iptables -P FORWARD DROP
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 192.168.0.2 -p tcp --dport 22 -j ACCEPT

If that doesn't work tell us exactly how you are testing it - which machine is 
the SSH client on, where is the server, what are the IP addresses...

Regards,

Antony.

-- 
It is also possible that putting the birds in a laboratory setting 
inadvertently renders them relatively incompetent.

 - Daniel C Dennet

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Antony Stone]

On Sunday 28 March 2004 10:15 pm, Cody Harris wrote:

> On Sun, 28 Mar 2004 21:48:46 +0100, Antony Stone wrote:
>
> > 4. Sorry for the way my mailer has mangled your rules, however please
> > post the output from "iptables -L FORWARD -nvx" (the v is important as it
> > shows the interface data which is not in the standard listing output).
>
> I did that. Check the other thread. Unless you want me to repost.

No, seen it already.   Thanks.

> > 5. How are you testing the setup?
>
> I created 2 unique usernames. And tested both. I got a freiend to try both.
> Phoneyuser on the firewall and night on the box i wanted. night didn't work
> but phoneyuser logged in ok

This is netfilter.   We're talking OSI layer 3/4, not layer 7.

That means I don't need to know about usernames & passwords, I need to know 
about IP addresses, where's the client, where's the server, etc.

Regards,

Antony.

-- 
If the human brain were so simple that we could understand it,
we'd be so simple that we couldn't.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Cody Harris]

It didn't work. I'm getting somebody on my ISP to test it (offsite). The firewall IPs are: 10.30.7.147 for net (my ISP nats it) and 192.168.0.1 and my box i want to forward to is 192.168.0.2. It still doesn't work. Here's an updated ruleset:


Chain INPUT (policy ACCEPT 3787 packets, 1815K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:10000
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:631
    3   144 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:http
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:smtp
    0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:ftp
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-reply
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp destination-unreachable
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp redirect
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-request
    0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp time-exceeded
    0     0 DROP       icmp --  eth0   any     anywhere             anywhere

Chain FORWARD (policy DROP 36 packets, 2291 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  any    any     anywhere             anywhere           state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  any    any     192.168.0.2          anywhere           tcp dpt:ssh

Chain OUTPUT (policy ACCEPT 3996 packets, 585K bytes)
 pkts bytes target     prot opt in     out     source               destination


On Sun, 28 Mar 2004 22:24:12 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Sunday 28 March 2004 10:07 pm, Cody Harris wrote:
> 
> > I rewrote the rules following your suggestions. It still doesn't work:
> >
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > target     prot opt in     out     source              destination
> > ACCEPT     all  --  eth1   any     anywhere             anywhere
> 
> Okay, that will allow all packets coming through from eth1
> 
> > ACCEPT     tcp  --  any    any     anywhere             192.168.0.2       
> > tcp dpt:ssh state RELATED,ESTABLISHED
> 
> That will allow packets coming through from 192.168.0.2 (which is plugged in 
> to eth1) to destination port 22.
> 
> You have no rule to allow the reply packets back (and the above rule won't 
> allow the NEW packets through, either).
> 
> Try this:
> 
> iptables -F FORWARD
> iptables -P FORWARD DROP
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A FORWARD -s 192.168.0.2 -p tcp --dport 22 -j ACCEPT
> 
> If that doesn't work tell us exactly how you are testing it - which machine is 
> the SSH client on, where is the server, what are the IP addresses...
> 
> Regards,
> 
> Antony.
> 
> -- 
> It is also possible that putting the birds in a laboratory setting 
> inadvertently renders them relatively incompetent.
> 
>  - Daniel C Dennet
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Cody Harris]

What other e-mails?

On Sun, 28 Mar 2004 22:15:59 +0100,
Someone named David Cannings <lists@edeca.net> wrote:

> On Sunday 28 March 2004 22:07, Cody Harris wrote:
> > I rewrote the rules following your suggestions. It still doesn't work:
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > any    any     anywhere             192.168.0.2        tcp dpt:ssh
> > state RELATED,ESTABLISHED
> 
> What I meant want a separate rule in FORWARD for established or related 
> packets.  However, please see the other mail I have just sent.
> 
> David
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Cody Harris]

It works once i ran this:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 22 -j DNAT --to 192.168.0.2:22

Why did i need that? Do i still need my other rules? (in my filter - forward chain)?

On Mon, 29 Mar 2004 15:51:47 -0400,
Someone named Cody Harris <hchs@ns.sympatico.ca> wrote:

> It didn't work. I'm getting somebody on my ISP to test it (offsite). The firewall IPs are: 10.30.7.147 for net (my ISP nats it) and 192.168.0.1 and my box i want to forward to is 192.168.0.2. It still doesn't work. Here's an updated ruleset:
> 
> 
> Chain INPUT (policy ACCEPT 3787 packets, 1815K bytes)
>  pkts bytes target     prot opt in     out     source               destination
>     0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:10000
>     0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:631
>     3   144 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:http
>     0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:smtp
>     0     0 DROP       tcp  --  eth0   any     anywhere             anywhere           tcp dpt:ftp
>     0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-reply
>     0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp destination-unreachable
>     0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp redirect
>     0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp echo-request
>     0     0 ACCEPT     icmp --  eth0   any     anywhere             anywhere           icmp time-exceeded
>     0     0 DROP       icmp --  eth0   any     anywhere             anywhere
> 
> Chain FORWARD (policy DROP 36 packets, 2291 bytes)
>  pkts bytes target     prot opt in     out     source               destination
>     0     0 ACCEPT     all  --  any    any     anywhere             anywhere           state RELATED,ESTABLISHED
>     0     0 ACCEPT     tcp  --  any    any     192.168.0.2          anywhere           tcp dpt:ssh
> 
> Chain OUTPUT (policy ACCEPT 3996 packets, 585K bytes)
>  pkts bytes target     prot opt in     out     source               destination
> 
> 
> 
> -- 
> +------------------+-----------------------------+
> | Cody Harris      | --------------------------- |
> | ---------------- | --------------------------- |
> +------------------+-------+---------------------+---+
> | *Sigh*. No key.                                    |
> +----------------------------------------------------+
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Antony Stone]

On Monday 29 March 2004 9:26 pm, Cody Harris wrote:

> It works once i ran this:
>
> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 22 -j DNAT --to
> 192.168.0.2:22
>
> Why did i need that? Do i still need my other rules? (in my filter -
> forward chain)?

You need a PREROUTING nat rule if you want the firewall to change the 
destination address where the packets are going to.

You need a FORWARD filter rule to allow the packets through the firewall 
(whether it's changed the destination address or not).

Regards,

Antony.

-- 
The first fifty percent of an engineering project takes ninety percent of the 
time, and the remaining fifty percent takes another ninety percent of the 
time.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Cody Harris]

On Mon, 29 Mar 2004 22:42:16 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Monday 29 March 2004 9:26 pm, Cody Harris wrote:
> 
> > It works once i ran this:
> >
> > iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 22 -j DNAT --to
> > 192.168.0.2:22
> >
> > Why did i need that? Do i still need my other rules? (in my filter -
> > forward chain)?
> 
> You need a PREROUTING nat rule if you want the firewall to change the 
> destination address where the packets are going to.

Oh, i get it. But if i didn't re-route the packet it would just go to this computer like it was? So i needed to preroute the packets to the correct box, right?

> 
> You need a FORWARD filter rule to allow the packets through the firewall 
> (whether it's changed the destination address or not).

So the forward rule filters the packets that are forwarded. It's not the part that makes the routing decision, like pre and postrouting are?

> 
> Regards,
> 
> Antony.
> 
> -- 
> The first fifty percent of an engineering project takes ninety percent of the 
> time, and the remaining fifty percent takes another ninety percent of the 
> time.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Antony Stone]

On Monday 29 March 2004 11:56 pm, Cody Harris wrote:

> On Mon, 29 Mar 2004 22:42:16 +0100, Antony Stone wrote:
>
> > You need a PREROUTING nat rule if you want the firewall to change the
> > destination address where the packets are going to.
>
> Oh, i get it. But if i didn't re-route the packet it would just go to this
> computer like it was? So i needed to preroute the packets to the correct
> box, right?
>
> > You need a FORWARD filter rule to allow the packets through the firewall
> > (whether it's changed the destination address or not).
>
> So the forward rule filters the packets that are forwarded. It's not the
> part that makes the routing decision, like pre and postrouting are?

I think you've got it now.

The only thing I would comment on what you said above is the phrase "routing 
decision":

Netfilter does not make routing desicions - the Linux kernel does that, even 
when you're not running netfilter.   Netfilter simply adds the ability to 
drop some packets *instead* of routing them on (in the filter tables), or to 
change where they're addressed to (in the nat table), although note in the 
latter case it's still the kernel routing mechanism which decides how they 
get to their (new) destination.

I sometimes tell people "a firewall is a router which can say No".

Regards,

Antony.

-- 
How I want a drink, alcoholic of course, after the heavy chapters involving 
quantum mechanics.

 - 3.14159265358979

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Not forwarding?

[Cody Harris]

On Tue, 30 Mar 2004 08:48:16 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Monday 29 March 2004 11:56 pm, Cody Harris wrote:
> 
> I think you've got it now.

Great!

> 
> The only thing I would comment on what you said above is the phrase "routing 
> decision":
> 
> Netfilter does not make routing desicions - the Linux kernel does that, even 
> when you're not running netfilter.   Netfilter simply adds the ability to 
> drop some packets *instead* of routing them on (in the filter tables), or to 
> change where they're addressed to (in the nat table), although note in the 
> latter case it's still the kernel routing mechanism which decides how they 
> get to their (new) destination.

So instead of changing the decision, it changes the packet to change the routing decision? If we've covered the NAT table, what's the mangle table?

> 
> I sometimes tell people "a firewall is a router which can say No".
> 
> Regards,
> 
> Antony.
> 
> -- 
> How I want a drink, alcoholic of course, after the heavy chapters involving 
> quantum mechanics.
> 
>  - 3.14159265358979
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Not forwarding?

[Antony Stone]

On Tuesday 30 March 2004 12:33 pm, Cody Harris wrote:

> On Tue, 30 Mar 2004 08:48:16 +0100, Antony Stone wrote:
> >
> > I think you've got it now.
>
> Great!
>
> > Netfilter does not make routing desicions - the Linux kernel does that,
> > even when you're not running netfilter.   Netfilter simply adds the
> > ability to drop some packets *instead* of routing them on (in the filter
> > tables), or to change where they're addressed to (in the nat table).
>
> So instead of changing the decision, it changes the packet to change the
> routing decision?

Yes, I'd say that's a good way of putting it.

> If we've covered the NAT table, what's the mangle table?

Tha mangle table is aptly named, and allows you to fiddle about with bits of 
the packets headers which most people wouldn't even think of changing - 
things like the TTL (Time To Live) field, the TOS (Type Of Service) field, 
and for MARKing packets (which doesn't actually change the packet, but allows 
netfilter to carry a special marker around with the packet during further 
processing).

Regards,

Antony.

-- 
The truth is rarely pure, and never simple.

 - Oscar Wilde

                                                     Please reply to the list;
                                                           please don't CC me.

Adding a flag to a packet

[Cody Harris]

On Tue, 30 Mar 2004 12:53:18 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:
> > If we've covered the NAT table, what's the mangle table?
> 
> Tha mangle table is aptly named, and allows you to fiddle about with bits of 
> the packets headers which most people wouldn't even think of changing - 
> things like the TTL (Time To Live) field, the TOS (Type Of Service) field, 
> and for MARKing packets (which doesn't actually change the packet, but allows 
> netfilter to carry a special marker around with the packet during further 
> processing).

Is it possible, with the mangling table, to edit the packet to have a special flag? So that when it hits another firewall that's setup correctly, it sends it to a pre-configured ip? Example:

On my internet network, the ip range is 192.168.0.0 to 255. If a computer sent a packet to 192.168.1.5, the computer used the gateway, slapped a flag on it, sent it to 1.2.3.4, the firewall there saw the flag, changed the ip on it to 192.168.1.5 coming from 192.168.0.6. When the computer sent a response, it just revered the process.

(I'm implying that the flag does NOT carry the dest-ip information, but simply has a numerical number, or something unquie to tell the firewalls to do this.)

> 
> Regards,
> 
> Antony.
> 
> -- 
> The truth is rarely pure, and never simple.
> 
>  - Oscar Wilde
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Antony Stone]

On Tuesday 30 March 2004 9:01 pm, Cody Harris wrote:

> On Tue, 30 Mar 2004 12:53:18 +0100, Antony Stone wrote:
>
> > > If we've covered the NAT table, what's the mangle table?
> >
> > The mangle table is aptly named, and allows you to fiddle about with bits
> > of the packets headers which most people wouldn't even think of changing
> > - things like the TTL (Time To Live) field, the TOS (Type Of Service)
> > field, and for MARKing packets (which doesn't actually change the packet,
> > but allows netfilter to carry a special marker around with the packet
> > during further processing).
>
> Is it possible, with the mangling table, to edit the packet to have a
> special flag?

Yes..... sort of...

> So that when it hits another firewall that's setup correctly,
> it sends it to a pre-configured ip? Example:

No.   Not with MARK, anyway.

I said "sort of" because the MARK value is not actually part of the packet 
(not even part of the header) - it's just something that netfilter associates 
with the packet whilst it's wandering around the machine which MARKed it.   
As soon as the packet leaves the machine, the MARK disappears.

> On my internet network, the ip range is 192.168.0.0 to 255. If a computer
> sent a packet to 192.168.1.5, the computer used the gateway, slapped a flag
> on it, sent it to 1.2.3.4, the firewall there saw the flag, changed the ip
> on it to 192.168.1.5 coming from 192.168.0.6. When the computer sent a
> response, it just reversed the process.

Sorry, I don't quite follow what you're suggesting here.   Let me quote it 
back to you with some questions inserted:

> On my internet network, the ip range is 192.168.0.0 to 255. If a computer

A computer where?

> sent a packet to 192.168.1.5,

You do recognise that a 192.168.x.y address is not routable across the 
Internet, yes?   It might go one or two hops, but will pertty soon get 
dropped.

> the computer used the gateway, slapped a flag
> on it, sent it to 1.2.3.4,

Now that *is* a routable address, but I think you only gave it as an example - 
where are you suggesting that this destination might be?   Across a local 
network which you have total control of, or somewhere around the Internet?

> the firewall there saw the flag, changed the ip

Which IP?   Source or destination (or both)?

> on it to 192.168.1.5 coming from 192.168.0.6.

Who's 192.168.0.6?   The real sender?   A fake?   Why choose this address?

> When the computer sent a response, it just reversed the process.

I've chosen the sig on this email especially for you this time :)

Regards,

Antony.

-- 
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Adding a flag to a packet

[Cody Harris]

On Tue, 30 Mar 2004 21:24:18 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Tuesday 30 March 2004 9:01 pm, Cody Harris wrote:
> 
> > On Tue, 30 Mar 2004 12:53:18 +0100, Antony Stone wrote:
> >
> > > > If we've covered the NAT table, what's the mangle table?
> > >
> > > The mangle table is aptly named, and allows you to fiddle about with bits
> > > of the packets headers which most people wouldn't even think of changing
> > > - things like the TTL (Time To Live) field, the TOS (Type Of Service)
> > > field, and for MARKing packets (which doesn't actually change the packet,
> > > but allows netfilter to carry a special marker around with the packet
> > > during further processing).
> >
> > Is it possible, with the mangling table, to edit the packet to have a
> > special flag?
> 
> Yes..... sort of...
> 
> > So that when it hits another firewall that's setup correctly,
> > it sends it to a pre-configured ip? Example:
> 
> No.   Not with MARK, anyway.
> 
> I said "sort of" because the MARK value is not actually part of the packet 
> (not even part of the header) - it's just something that netfilter associates 
> with the packet whilst it's wandering around the machine which MARKed it.   
> As soon as the packet leaves the machine, the MARK disappears.
> 
> > On my internet network, the ip range is 192.168.0.0 to 255. If a computer
> > sent a packet to 192.168.1.5, the computer used the gateway, slapped a flag
> > on it, sent it to 1.2.3.4, the firewall there saw the flag, changed the ip
> > on it to 192.168.1.5 coming from 192.168.0.6. When the computer sent a
> > response, it just reversed the process.
> 
> Sorry, I don't quite follow what you're suggesting here.   Let me quote it 
> back to you with some questions inserted:
> 
> > On my internet network, the ip range is 192.168.0.0 to 255. If a computer
> 
> A computer where?

On MY network.

> 
> > sent a packet to 192.168.1.5,
> 
> You do recognise that a 192.168.x.y address is not routable across the 
> Internet, yes?   It might go one or two hops, but will pertty soon get 
> dropped.

But once it hits my firewall the IP changes to 1.2.3.4.

> 
> > the computer used the gateway, slapped a flag
> > on it, sent it to 1.2.3.4,
> 
> Now that *is* a routable address, but I think you only gave it as an example - 
> where are you suggesting that this destination might be?   Across a local 
> network which you have total control of, or somewhere around the Internet?

Across the internet. Once at 1.2.3.4, it gets converted back to the lan'd ip (192.168.0.6).

> 
> > the firewall there saw the flag, changed the ip
> 
> Which IP?   Source or destination (or both)?

The destination. To be sent across the internet, the ip was changed to the destination firewall/gateway. Once it hits the gateway, it will be changed back to be routed to its destination.

> 
> > on it to 192.168.1.5 coming from 192.168.0.6.
> 
> Who's 192.168.0.6?   The real sender?   A fake?   Why choose this address?

A real sender. Or hypothetical sender. I don't "Actually" have the ip, it WOULD be 192.168.0.2 sending to 192.168.1.2. As both the .1s are the firewalls from the inside.

> 
> > When the computer sent a response, it just reversed the process.
> 
> I've chosen the sig on this email especially for you this time :)

Hahaha.

So estentally (SP), i want to  create a "patch" between to physical networks transparently. So as far as the internet network computers (192.168.*.*) are concerned, they're phsically attached. The 192.168.0.* system is actually a different physical site then 192.168.1.*. Just when one sends to the other, it's altered to send accross the net and re-wrote at the other end and it continues on it's marry way.

Get it? lol

> 
> Regards,
> 
> Antony.
> 
> -- 
> 90% of networking problems are routing problems.
> 9 of the remaining 10% are routing problems in the other direction.
> The remaining 1% might be something else, but check the routing anyway.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Antony Stone]

On Tuesday 30 March 2004 9:35 pm, Cody Harris wrote:

> So estentally (SP), i want to  create a "patch" between to physical
> networks transparently. So as far as the internet network computers
> (192.168.*.*) are concerned, they're phsically attached. The 192.168.0.*
> system is actually a different physical site then 192.168.1.*. Just when
> one sends to the other, it's altered to send accross the net and re-wrote
> at the other end and it continues on it's marry way.

Okay.   You want a VPN (I use http://www.freeswan.org), a simple IP tunnel 
(http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.ip-ip.html), or 
else some clever DNAT rules one end, and SNAT rules the other.

Regards,

Antony.

Re: Adding a flag to a packet

[Cody Harris]

On Tue, 30 Mar 2004 21:50:40 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Tuesday 30 March 2004 9:35 pm, Cody Harris wrote:
> 
> > So estentally (SP), i want to  create a "patch" between to physical
> > networks transparently. So as far as the internet network computers
> > (192.168.*.*) are concerned, they're phsically attached. The 192.168.0.*
> > system is actually a different physical site then 192.168.1.*. Just when
> > one sends to the other, it's altered to send accross the net and re-wrote
> > at the other end and it continues on it's marry way.
> 
> Okay.   You want a VPN (I use http://www.freeswan.org), a simple IP tunnel 
> (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.ip-ip.html), or 
> else some clever DNAT rules one end, and SNAT rules the other.

So i *can't* simple mark a packet with a flag that the other one can see? What if i change the ttl to something like 1000 and match it with a rule on the other end (too weed out any other instances of this).

> 
> Regards,
> 
> Antony.
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Antony Stone]

On Tuesday 30 March 2004 10:06 pm, Cody Harris wrote:

> On Tue, 30 Mar 2004 21:50:40 +0100, Antony Stone wrote:
> >
> > Okay.   You want a VPN (I use http://www.freeswan.org), a simple IP
> > tunnel
> > (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.ip-ip.html), or
> > else some clever DNAT rules one end, and SNAT rules the other.
>
> So i *can't* simple mark a packet with a flag that the other one can see?

No.   The MARK is not a part of the actual packet or header - it's just 
something that netfilter associates with the packet whilst it's processing 
it.   Once the packet leaves the box, it's just a plain packet again, and the 
MARK is gone.

> What if i change the ttl to something like 1000 and match it with a rule on
> the other end (too weed out any other instances of this).

Well, the TTL field is only 8 bits, so the maximum value is 255 :)   But 
anyway, you're trying to make custard by boiling a chicken.   It's just the 
wrong way to approach the problem.

Netfilter is a Firewall, and it can also do a bit of NATting.   It's bad 
enough when people try to make it do (local) routing, let alone attempt to 
convert it into a VPN.

There are other ways to do what you want, and the IP tunnel solution is not at 
all complicated (however it is not at all secure, either - packets are 
transferred across the Internet between the two networks with no encryption 
or other attempt to hide the contents).

Regards,

Antony.

-- 
Success is a lousy teacher.  It seduces smart people into thinking they can't 
lose.

 - William H Gates III

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Adding a flag to a packet

[Cody Harris]

On Tue, 30 Mar 2004 22:23:33 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Tuesday 30 March 2004 10:06 pm, Cody Harris wrote:
> 
> > On Tue, 30 Mar 2004 21:50:40 +0100, Antony Stone wrote:
> > >
> > > Okay.   You want a VPN (I use http://www.freeswan.org), a simple IP
> > > tunnel
> > > (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.ip-ip.html), or
> > > else some clever DNAT rules one end, and SNAT rules the other.
> >
> > So i *can't* simple mark a packet with a flag that the other one can see?
> 
> No.   The MARK is not a part of the actual packet or header - it's just 
> something that netfilter associates with the packet whilst it's processing 
> it.   Once the packet leaves the box, it's just a plain packet again, and the 
> MARK is gone.
> 
> > What if i change the ttl to something like 1000 and match it with a rule on
> > the other end (too weed out any other instances of this).
> 
> Well, the TTL field is only 8 bits, so the maximum value is 255 :)   But 
> anyway, you're trying to make custard by boiling a chicken.   It's just the 
> wrong way to approach the problem.
> 
> Netfilter is a Firewall, and it can also do a bit of NATting.   It's bad 
> enough when people try to make it do (local) routing, let alone attempt to 
> convert it into a VPN.
> 
> There are other ways to do what you want, and the IP tunnel solution is not at 
> all complicated (however it is not at all secure, either - packets are 
> transferred across the Internet between the two networks with no encryption 
> or other attempt to hide the contents).

Would the VPN also transmit the lan-based packets (such as the ones needed to run games).

Anyways, it feels like i know you presonnally now...hows the wife and the kids? Hehehe. I could actually carry out this coversation on an imclient. But i feel we're just about done. If you *do*, and you have msn add charris@vectec.net.



> 
> Regards,
> 
> Antony.
> 
> -- 
> Success is a lousy teacher.  It seduces smart people into thinking they can't 
> lose.
> 
>  - William H Gates III
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Antony Stone]

On Tuesday 30 March 2004 10:28 pm, Cody Harris wrote:

> On Tue, 30 Mar 2004 22:23:33 +0100, Antony Stone wrote:
> >
> > There are other ways to do what you want, and the IP tunnel solution is
> > not at all complicated (however it is not at all secure, either - packets
> > are transferred across the Internet between the two networks with no
> > encryption or other attempt to hide the contents).
>
> Would the VPN also transmit the lan-based packets (such as the ones needed
> to run games).

A VPN will route anything - just like a standard router - except that the 
traffic is hidden (encrypted) as it passes across the Internet.   Basically, 
if you imagine having a router with two interfaces, one connected to network 
A and the other connected to network B, except the networks are a few 
thousand miles apart, that's what a VPN does for you.

Regards,

Antony.

-- 
One good tern deserves another.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Adding a flag to a packet

[Tony Earnshaw]

tir, 30.03.2004 kl. 22.35 skrev Cody Harris:

[...]

> > > When the computer sent a response, it just reversed the process.
> > 
> > I've chosen the sig on this email especially for you this time :)
> 
> Hahaha.
> 
> So estentally (SP), i want to  create a "patch" between to physical
> networks transparently. So as far as the internet network computers
> (192.168.*.*) are concerned, they're phsically attached. The
> 192.168.0.* system is actually a different physical site then
> 192.168.1.*. Just when one sends to the other, it's altered to send
> accross the net and re-wrote at the other end and it continues on it's
> marry way.
> 
> Get it? lol

Hmmm ... to my mind you've just made an "unfriend" (uvenn) of one of the
gentlemen on this mailing list. On each mailing list there are one or
two gentlemen. These are those whom it is unwise (uklokt) to tangle
with. Even when one has had one or two.

--Tonni

-- 

mail: billy - at - billy.demon.nl
http://www.billy.demon.nl

Re: Adding a flag to a packet

[Cody Harris]

Thanks. You helped a lot. Hopefully i can take it from here!

On Tue, 30 Mar 2004 22:40:29 +0100,
Someone named Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> On Tuesday 30 March 2004 10:28 pm, Cody Harris wrote:
> 
> > On Tue, 30 Mar 2004 22:23:33 +0100, Antony Stone wrote:
> > >
> > > There are other ways to do what you want, and the IP tunnel solution is
> > > not at all complicated (however it is not at all secure, either - packets
> > > are transferred across the Internet between the two networks with no
> > > encryption or other attempt to hide the contents).
> >
> > Would the VPN also transmit the lan-based packets (such as the ones needed
> > to run games).
> 
> A VPN will route anything - just like a standard router - except that the 
> traffic is hidden (encrypted) as it passes across the Internet.   Basically, 
> if you imagine having a router with two interfaces, one connected to network 
> A and the other connected to network B, except the networks are a few 
> thousand miles apart, that's what a VPN does for you.
> 
> Regards,
> 
> Antony.
> 
> -- 
> One good tern deserves another.
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Cody Harris]

On Wed, 31 Mar 2004 00:12:36 +0200,
Someone named Tony Earnshaw <tonye@billy.demon.nl> wrote:

> tir, 30.03.2004 kl. 22.35 skrev Cody Harris:
> 
> [...]
> 
> > > > When the computer sent a response, it just reversed the process.
> > > 
> > > I've chosen the sig on this email especially for you this time :)
> > 
> > Hahaha.
> > 
> > So estentally (SP), i want to  create a "patch" between to physical
> > networks transparently. So as far as the internet network computers
> > (192.168.*.*) are concerned, they're phsically attached. The
> > 192.168.0.* system is actually a different physical site then
> > 192.168.1.*. Just when one sends to the other, it's altered to send
> > accross the net and re-wrote at the other end and it continues on it's
> > marry way.
> > 
> > Get it? lol
> 
> Hmmm ... to my mind you've just made an "unfriend" (uvenn) of one of the
> gentlemen on this mailing list. On each mailing list there are one or
> two gentlemen. These are those whom it is unwise (uklokt) to tangle
> with. Even when one has had one or two.

I don't follow. Why?

> 
> --Tonni
> 
> -- 
> 
> mail: billy - at - billy.demon.nl
> http://www.billy.demon.nl
> 
> 


-- 
+------------------+-----------------------------+
| Cody Harris      | --------------------------- |
| ---------------- | --------------------------- |
+------------------+-------+---------------------+---+
| *Sigh*. No key.                                    |
+----------------------------------------------------+

Re: Adding a flag to a packet

[Antony Stone]

On Tuesday 30 March 2004 11:12 pm, Tony Earnshaw wrote:

> Hmmm ... to my mind you've just made an "unfriend" (uvenn) of one of the
> gentlemen on this mailing list. On each mailing list there are one or
> two gentlemen. These are those whom it is unwise (uklokt) to tangle
> with. Even when one has had one or two.

Thanks for the compliment, Tony, but I took Cody's words at face value and 
simply tried to understand what he was attempting with his network.

Incidentally, what does uklokt mean?   I tried a Google for it and only got 
Norwegian...

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Adding a flag to a packet

[Tony Earnshaw]

ons, 31.03.2004 kl. 01.46 skrev Antony Stone:

> Incidentally, what does uklokt mean?   I tried a Google for it and only got 
> Norwegian...

It means "unwise" ... in Norwegian ;)

Best

--Tonni

-- 

mail: billy - at - billy.demon.nl
http://www.billy.demon.nl

Re: Adding a flag to a packet

[Cedric Blancher]

Le mar 30/03/2004 à 23:28, Cody Harris a écrit :
> Would the VPN also transmit the lan-based packets (such as the ones
> needed to run games).

IPSEC VPNs are layer3 based, so they route traffic. They can't transmit
layer 2 frames. If you need this, you have basicly two solutions :

	. ARP proxy / frame diverter / ebtables solution based in order
	  to extract frames from local network and route their IP
	  payload through the tunnel to the destination (see ebtables[1]
	  website for documentation for such a setting)
	. OpenVPN[2] solution that allows layer2 VPN, but without any
	  interroperability


[1] http://ebtables.sourceforge.net/
[2] http://openvpn.sourceforge.net/

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: Adding a flag to a packet

[Cedric Blancher]

Le mar 30/03/2004 à 22:50, Antony Stone a écrit :
> Okay.   You want a VPN (I use http://www.freeswan.org), a simple IP tunnel 
> (http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.ip-ip.html), or 
> else some clever DNAT rules one end, and SNAT rules the other.

I would rather advise GRE tunnel use, for its better interroperability
(e.g. Linux IPIP tunnels are not totally functionnal with BSD ones).
Moreover, you can have multiple GRE tunnels, although, afaik, you can
only have one IPIP tunnel. BTW, you're totaly right, tunneling seems to
be the best answer to Cody's problem.

NAT based solution will need some packet flaging, usually performed
modifying TOS (instead of TTL). But packets may cross routers/firewalls
that can reject thoses packets or reset TOS value (or alter TTL).


My 0.02¤ to the discussion ;)

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!