thr3ads.net - Shorewall users - Shorewall and Counter-Strike: Source [May 2006]

If this information is useful, please help other people find it:
Share via:

Jan Mulders

2006-May-17 19:55 UTC

Shorewall and Counter-Strike: Source

Hello all,

I''m trying to host a Counter-Strike: Source server on my box, which has
two
interfaces, tun0 and eth0. (it''s running a VPN on tun0, with
connections
coming in on eth0).

The server is meant to listen on port 27015, tcp and udp protocols, on the
IP address 84.234.16.144. For the purposes of testing, I have been using
Netcat to listen on this port and IP, and Telnet to connect to this IP/port.

This is what I get from a filtered tcpdump:

Source   |  Destination   | Protocol  | Info
84.234.16.143 -> 84.234.16.144  TCP [SYN]
84.234.16.144 -> 84.234.16.143  TCP [SYN, ACK]
84.234.16.143 -> 84.234.16.144  TCP [ACK]
84.234.16.144 -> 84.234.16.143  TCP [FIN, ACK]
84.234.16.144 -> 84.234.16.143  TCP [RST, ACK]
84.234.16.143 -> 84.234.16.144  TCP [ACK]
84.234.16.144 -> 84.234.16.143  TCP [RST]

.143 is a client machine on tun0, .144 is one of the firewall machine''s
IPs.

The relevant rules in /rules are:

# accept half life 2 server sessions
ACCEPT:info     all             fw:84.234.16.144        all
ACCEPT:info     fw:84.234.16.144        all             all

I get the following showing up in my logs:

May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61103
DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=61109
DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0

... when trying to connect from the interface ''tun0''.

If anyone could shed some light onto this situation, I''d really
appreciate
it.

My full configuration is available here (sorry about the yousendit lameness,
the file''s 80kb):
http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3

Below is the information requested in the "Asking for Help" section of
the
Shorewall website.

Thanks,

Jan Mulders




0www~# /sbin/shorewall version
3.0.4
0www~#

0www~# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
    inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
    inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
    inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12
    inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2
    inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3
    inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13
    inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0
    inet6 fe80::20a:e6ff:fea6:849b/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
100
    link/[65534]
    inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
4: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
0www~#

0www~# ip route show
84.234.16.145 dev tun0  scope link
84.234.16.145 dev eth0  scope link  src 84.234.16.145
84.234.16.147 dev tun0  scope link
84.234.16.146 dev tun0  scope link
84.234.16.149 dev tun0  scope link
84.234.16.148 dev tun0  scope link
84.234.16.151 dev tun0  scope link
84.234.16.150 dev tun0  scope link
84.234.16.153 dev tun0  scope link
84.234.16.152 dev tun0  scope link
84.234.16.154 dev tun0  scope link
84.234.16.233 dev eth0  scope link
84.234.16.143 dev tun0  scope link
84.234.16.0/24 dev eth0  proto kernel  scope link  src 84.234.16.233
84.234.16.0/24 dev tun0  proto kernel  scope link  src 84.234.16.145
169.254.0.0/16 dev eth0  scope link
84.0.0.0/8 via 84.234.16.1 dev eth0
84.0.0.0/8 dev eth0  proto kernel  scope link  src 84.234.16.145
default via 84.234.16.1 dev eth0
0www~#

Werner vd Merwe

2006-May-18 07:09 UTC

head link

RE: Shorewall and Counter-Strike: Source

Hi Jan,

 

Not sure if maybe you should rather use bridge mode? We play a collection of
games over bridge mode, including CS:Source.

With the routing way, broadcasts are not transmitted over the tunnel, so
unless you can specify a server, I doubt if the clients will be able to
connect to it.

 

Hope it helps – happy huntin’

 

   _____  

From: shorewall-users-admin@lists.sourceforge.net
[mailto:shorewall-users-admin@lists.sourceforge.net] On Behalf Of Jan
Mulders
Sent: 17 May 2006 09:55 PM
To: shorewall-users@lists.sourceforge.net
Subject: [Shorewall-users] Shorewall and Counter-Strike: Source

 

Hello all,

I''m trying to host a Counter-Strike: Source server on my box, which has
two
interfaces, tun0 and eth0. (it''s running a VPN on tun0, with
connections
coming in on eth0).

The server is meant to listen on port 27015, tcp and udp protocols, on the
IP address HYPERLINK "http://84.234.16.144"84.234.16.144. For the
purposes
of testing, I have been using Netcat to listen on this port and IP, and
Telnet to connect to this IP/port.

This is what I get from a filtered tcpdump: 

Source   |  Destination   | Protocol  | Info
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144  TCP [SYN]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143  TCP [SYN, ACK]
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144  TCP [ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143  TCP [FIN, ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143  TCP [RST, ACK]
HYPERLINK "http://84.234.16.143"84.234.16.143 -> HYPERLINK
"http://84.234.16.144"84.234.16.144   TCP [ACK]
HYPERLINK "http://84.234.16.144"84.234.16.144 -> HYPERLINK
"http://84.234.16.143"84.234.16.143  TCP [RST]

.143 is a client machine on tun0, .144 is one of the firewall machine''s
IPs.

The relevant rules in /rules are: 

# accept half life 2 server sessions
ACCEPT:info     all             fw:HYPERLINK
"http://84.234.16.144"84.234.16.144        all
ACCEPT:info     fw:HYPERLINK "http://84.234.16.144"84.234.16.144      
all
all 

I get the following showing up in my logs:

May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MACSRC=HYPERLINK "http://84.234.16.143"84.234.16.143 DST=HYPERLINK
"http://84.234.16.233"84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61103 DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MACSRC=HYPERLINK "http://84.234.16.143" 84.234.16.143 DST=HYPERLINK
"http://84.234.16.233"84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61109 DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0

... when trying to connect from the interface ''tun0''. 

If anyone could shed some light onto this situation, I''d really
appreciate
it.

My full configuration is available here (sorry about the yousendit lameness,
the file''s 80kb): HYPERLINK
"http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3
"http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3

Below is the information requested in the "Asking for Help" section of
the
Shorewall website.

Thanks,

Jan Mulders 




0www~# /sbin/shorewall version
3.0.4
0www~#

0www~# ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet HYPERLINK "http://127.0.0.1/8"127.0.0.1/8 brd HYPERLINK
"http://127.255.255.255"127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 
    link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
    inet HYPERLINK "http://84.234.16.233/24"84.234.16.233/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global eth0
    inet HYPERLINK "http://84.234.16.145/8"84.234.16.145/8 brd
HYPERLINK
"http://84.255.255.255"84.255.255.255 scope global eth0:1
    inet HYPERLINK "http://84.234.16.154/24"84.234.16.154/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:12 
    inet HYPERLINK "http://84.234.16.144/24"84.234.16.144/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:2
    inet HYPERLINK "http://84.234.16.145/24"84.234.16.145/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:3
    inet HYPERLINK "http://84.234.16.155/24"84.234.16.155/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global secondary eth0:13 
    inet HYPERLINK "http://84.234.16.144/8"84.234.16.144/8 brd
HYPERLINK
"http://84.255.255.255"84.255.255.255 scope global secondary eth0:0
    inet6 fe80::20a:e6ff:fea6:849b/64 scope link
       valid_lft forever preferred_lft forever 
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen
100
    link/[65534]
    inet HYPERLINK "http://84.234.16.145/24"84.234.16.145/24 brd
HYPERLINK
"http://84.234.16.255"84.234.16.255 scope global tun0
4: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit HYPERLINK "http://0.0.0.0"0.0.0.0 brd HYPERLINK
"http://0.0.0.0"0.0.0.0
0www~#

0www~# ip route show
HYPERLINK "http://84.234.16.145"84.234.16.145 dev tun0  scope link
HYPERLINK "http://84.234.16.145"84.234.16.145 dev eth0  scope link 
src
HYPERLINK "http://84.234.16.145"84.234.16.145
HYPERLINK "http://84.234.16.147"84.234.16.147 dev tun0  scope link 
HYPERLINK "http://84.234.16.146"84.234.16.146 dev tun0  scope link
HYPERLINK "http://84.234.16.149"84.234.16.149 dev tun0  scope link
HYPERLINK "http://84.234.16.148"84.234.16.148 dev tun0  scope link
HYPERLINK "http://84.234.16.151"84.234.16.151 dev tun0  scope link
HYPERLINK "http://84.234.16.150"84.234.16.150 dev tun0  scope link
HYPERLINK "http://84.234.16.153"84.234.16.153 dev tun0  scope link
HYPERLINK "http://84.234.16.152"84.234.16.152 dev tun0  scope link
HYPERLINK "http://84.234.16.154"84.234.16.154 dev tun0  scope link
HYPERLINK "http://84.234.16.233"84.234.16.233 dev eth0  scope link
HYPERLINK "http://84.234.16.143"84.234.16.143 dev tun0  scope link
HYPERLINK "http://84.234.16.0/24"84.234.16.0/24 dev eth0  proto kernel
scope link  src HYPERLINK "http://84.234.16.233"84.234.16.233
HYPERLINK "http://84.234.16.0/24"84.234.16.0/24 dev tun0  proto kernel
scope link  src HYPERLINK "http://84.234.16.145"84.234.16.145
HYPERLINK "http://169.254.0.0/16"169.254.0.0/16 dev eth0  scope link
HYPERLINK "http://84.0.0.0/8"84.0.0.0/8 via HYPERLINK
"http://84.234.16.1"84.234.16.1 dev eth0
HYPERLINK "http://84.0.0.0/8"84.0.0.0/8 dev eth0  proto kernel  scope
link
src HYPERLINK "http://84.234.16.145"84.234.16.145
default via HYPERLINK "http://84.234.16.1"84.234.16.1 dev eth0 
0www~#






--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17

Jan Mulders

2006-May-18 11:40 UTC

head link

Re: Shorewall and Counter-Strike: Source

I''ve tested from both sides of the system (eth0 and tun0) - and I get
the
same result - the connection gets terminated by the server (presumably
firewall) - which points to it not being a bridged vs routed issue.

CS Source doesn''t use multicast either.. but thanks for the suggestion
:)

Regards,

Jan Mulders

On 18/05/06, Werner vd Merwe <werner@saicom.co.za>
wrote:>
>  Hi Jan,
>
>
>
> Not sure if maybe you should rather use bridge mode? We play a collection
> of games over bridge mode, including CS:Source.
>
> With the routing way, broadcasts are not transmitted over the tunnel, so
> unless you can specify a server, I doubt if the clients will be able to
> connect to it.
>
>
>
> Hope it helps – happy huntin''
>
>
>  ------------------------------
>
> *From:* shorewall-users-admin@lists.sourceforge.net [mailto:
> shorewall-users-admin@lists.sourceforge.net] *On Behalf Of *Jan Mulders
> *Sent:* 17 May 2006 09:55 PM
> *To:* shorewall-users@lists.sourceforge.net
> *Subject:* [Shorewall-users] Shorewall and Counter-Strike: Source
>
>
>
> Hello all,
>
> I''m trying to host a Counter-Strike: Source server on my box,
which has
> two interfaces, tun0 and eth0. (it''s running a VPN on tun0, with
connections
> coming in on eth0).
>
> The server is meant to listen on port 27015, tcp and udp protocols, on the
> IP address 84.234.16.144. For the purposes of testing, I have been using
> Netcat to listen on this port and IP, and Telnet to connect to this
IP/port.
>
> This is what I get from a filtered tcpdump:
>
> Source   |  Destination   | Protocol  | Info
> 84.234.16.143 -> 84.234.16.144  TCP [SYN]
> 84.234.16.144 -> 84.234.16.143  TCP [SYN, ACK]
> 84.234.16.143 -> 84.234.16.144  TCP [ACK]
> 84.234.16.144 -> 84.234.16.143  TCP [FIN, ACK]
> 84.234.16.144 -> 84.234.16.143  TCP [RST, ACK]
> 84.234.16.143 -> 84.234.16.144   TCP [ACK]
> 84.234.16.144 -> 84.234.16.143  TCP [RST]
>
> .143 is a client machine on tun0, .144 is one of the firewall
machine''s
> IPs.
>
> The relevant rules in /rules are:
>
> # accept half life 2 server sessions
> ACCEPT:info     all             fw:84.234.16.144        all
> ACCEPT:info     fw:84.234.16.144        all             all
>
> I get the following showing up in my logs:
>
> May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61103
> DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
> May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC=84.234.16.143DST> 84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61109 DF PROTO=TCP
> SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
>
> ... when trying to connect from the interface ''tun0''.
>
> If anyone could shed some light onto this situation, I''d really
appreciate
> it.
>
> My full configuration is available here (sorry about the yousendit
> lameness, the file''s 80kb):
>
http://www.yousendit.com/transfer.php?action=download&ufid=6A10E8FD7B9594A3
>
> Below is the information requested in the "Asking for Help"
section of the
> Shorewall website.
>
> Thanks,
>
> Jan Mulders
>
>
>
>
> 0www~# /sbin/shorewall version
> 3.0.4
> 0www~#
>
> 0www~# ip addr show
> 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>     link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
>     inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
>     inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
>     inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12
>
>     inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2
>     inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3
>     inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13
>
>     inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0
>     inet6 fe80::20a:e6ff:fea6:849b/64 scope link
>        valid_lft forever preferred_lft forever
> 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast
qlen
> 100
>     link/[65534]
>     inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
> 4: sit0: <NOARP> mtu 1480 qdisc noop
>     link/sit 0.0.0.0 brd 0.0.0.0
> 0www~#
>
> 0www~# ip route show
> 84.234.16.145 dev tun0  scope link
> 84.234.16.145 dev eth0  scope link  src 84.234.16.145
> 84.234.16.147 dev tun0  scope link
> 84.234.16.146 dev tun0  scope link
> 84.234.16.149 dev tun0  scope link
> 84.234.16.148 dev tun0  scope link
> 84.234.16.151 dev tun0  scope link
> 84.234.16.150 dev tun0  scope link
> 84.234.16.153 dev tun0  scope link
> 84.234.16.152 dev tun0  scope link
> 84.234.16.154 dev tun0  scope link
> 84.234.16.233 dev eth0  scope link
> 84.234.16.143 dev tun0  scope link
> 84.234.16.0/24 dev eth0  proto kernel  scope link  src 84.234.16.233
> 84.234.16.0/24 dev tun0  proto kernel  scope link  src 84.234.16.145
> 169.254.0.0/16 dev eth0  scope link
> 84.0.0.0/8 via 84.234.16.1 dev eth0
> 84.0.0.0/8 dev eth0  proto kernel  scope link  src 84.234.16.145
> default via 84.234.16.1 dev eth0
> 0www~#
>
>
>
>
>  --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 2006/05/17
>

Tom Eastep

2006-May-18 13:30 UTC

head link

Re: Shorewall and Counter-Strike: Source

Jan Mulders wrote:
> 
> I get the following showing up in my logs:
> 
> May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61103
> DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
> May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC> 84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61109
> DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
> 
> ... when trying to connect from the interface ''tun0''.
So traffic from 84.234.16.233 enters tun0 destined for 84.234.16.233

> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>    link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
>    inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
Which happens to be the primary IP address of eth0.
>    inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
>    inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary eth0:12
>    inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2
>    inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3
>    inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary eth0:13
>    inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0
>    inet6 fe80::20a:e6ff:fea6:849b/64 scope link
>       valid_lft forever preferred_lft forever
> 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc pfifo_fast
qlen
> 100
>    link/[65534]
>    inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
Strangely, tun0 is configured with the same network as eth0!
> 
> 0www~# ip route show
> 84.234.16.145 dev tun0  scope link
> 84.234.16.145 dev eth0  scope link  src 84.234.16.145
> 84.234.16.147 dev tun0  scope link
> 84.234.16.146 dev tun0  scope link
> 84.234.16.149 dev tun0  scope link
> 84.234.16.148 dev tun0  scope link
> 84.234.16.151 dev tun0  scope link
> 84.234.16.150 dev tun0  scope link
> 84.234.16.153 dev tun0  scope link
> 84.234.16.152 dev tun0  scope link
> 84.234.16.154 dev tun0  scope link
> 84.234.16.233 dev eth0  scope link
> 84.234.16.143 dev tun0  scope link
> 84.234.16.0/24 dev eth0  proto kernel  scope link  src 84.234.16.233
And the first route to 84.234.16.233 goes out of eth0. So when the
firewall responds, the response is sent via eth0 rather than via tun0.
> 84.234.16.0/24 dev tun0  proto kernel  scope link  src 84.234.16.145
> 169.254.0.0/16 dev eth0  scope link
> 84.0.0.0/8 via 84.234.16.1 dev eth0
> 84.0.0.0/8 dev eth0  proto kernel  scope link  src 84.234.16.145
> default via 84.234.16.1 dev eth0
> 0www~#
> 
Once again, it''s good to keep in mind that not all connection problems
are Shorewall problems. This appears to be a case of a totally
unworkable IP/VPN configuration.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep

2006-May-18 13:43 UTC

head link

Re: Shorewall and Counter-Strike: Source

I cut and pasted the wrong source IP address the first time -- what
follows is hopefully correct:


Jan Mulders wrote:

>I get the following showing up in my logs:
>
>May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC>84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61103
>DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
>May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT= MAC=
SRC>84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00 TTL=127
ID=61109
>DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
>
>... when trying to connect from the interface ''tun0''.
> 
So traffic from 84.234.16.143 enters tun0 destined for 84.234.16.233
> 
>>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen
1000
>>   link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
>>   inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
> 
Which happens to be the primary IP address of eth0.
> 
>>   inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
>>   inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary
eth0:12
>>   inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary eth0:2
>>   inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary eth0:3
>>   inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary
eth0:13
>>   inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary eth0:0
>>   inet6 fe80::20a:e6ff:fea6:849b/64 scope link
>>      valid_lft forever preferred_lft forever
>>3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
pfifo_fast qlen
>>100
>>   link/[65534]
>>   inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
> 
Strangely, tun0 is configured with the same network as eth0!
> 
>>0www~# ip route show
>>84.234.16.145 dev tun0  scope link
>>84.234.16.145 dev eth0  scope link  src 84.234.16.145
>>84.234.16.147 dev tun0  scope link
>>84.234.16.146 dev tun0  scope link
>>84.234.16.149 dev tun0  scope link
>>84.234.16.148 dev tun0  scope link
>>84.234.16.151 dev tun0  scope link
>>84.234.16.150 dev tun0  scope link
>>84.234.16.153 dev tun0  scope link
>>84.234.16.152 dev tun0  scope link
>>84.234.16.154 dev tun0  scope link
>>84.234.16.233 dev eth0  scope link
>>84.234.16.143 dev tun0  scope link
>>84.234.16.0/24 dev eth0  proto kernel  scope link  src 84.234.16.233
> 
And the first route to 84.234.16.143 goes out of eth0. So when the
firewall responds, the response is sent via eth0 rather than via tun0.

>>84.234.16.0/24 dev tun0  proto kernel  scope link  src 84.234.16.145
>>169.254.0.0/16 dev eth0  scope link
>>84.0.0.0/8 via 84.234.16.1 dev eth0
>>84.0.0.0/8 dev eth0  proto kernel  scope link  src 84.234.16.145
>>default via 84.234.16.1 dev eth0
>>0www~#
>>
> 
Once again, it''s good to keep in mind that not all connection problems
are Shorewall problems. This appears to be a case of a totally
unworkable IP/VPN/routing configuration.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Jan Mulders

2006-May-19 08:46 UTC

head link

Re: Shorewall and Counter-Strike: Source

Right.

Do I ''just'' need to fix my routing to have a workable
configuration, or do I
need to rethink my entire setup? What would be a more correct/workable way
of configuring this network? (see below)

If nobody''s willing to explain to me how I should fix my routing setup
(or
rather, show me how it should''ve been designed in the first place),
would
anyone happen to have a link to where I should be reading up on
network/routing design techniques?

The original idea was to have .233 (the server''s main IP) seperate from
the
others, not involved in the vpn/routing at all, and to have .145 as the main
IP used for the VPN/routing. See diagram below:


Internet (eth0) ==== Webserver IP (.233)

Internet (eth0) ==== VPN/Routing IP (.145) ==== Clients on VPN (tun0) ===Clients
(.143 etc)

The routing table on clients should be:
-- specific routes for client''s proxy go here --
0.0.0.0         84.234.16.145     0.0.0.0         UG    0      0        0
tun0

and my server should be:
84.234.16.143   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
84.234.16.147   0.0.0.0         255.255.255.255 UH    0      0        0 tun0
0.0.0.0         84.234.16.1     0.0.0.0         UG    0      0        0 eth0

is this pretty much all I need for an example with two clients (.143 and
.147)?
Do I need to use the following to tell routing that some IPs are local, and
if they come in on certain interfaces they need to be accepted?

Do I add in routes for

/sbin/route add -host 84.234.16.233 dev eth0
/sbin/route add -host 84.234.16.145 dev eth0:0
/sbin/route add -host 84.234.16.145 dev tun0



What is the order in which routing, iptables and my server''s daemons
interact? Which comes first?

Do I need different IPs for eth0 and tun0? Say, .233 for eth0, and .145 for
tun0? What happens when a packet comes in destined for .233 on .145?

Thanks for your assistance. I hope to understand this all by the time
I''m
done here :-)

Regards,

Jan Mulders

On 18/05/06, Tom Eastep <teastep@shorewall.net>
wrote:>
> I cut and pasted the wrong source IP address the first time -- what
> follows is hopefully correct:
>
>
> Jan Mulders wrote:
>
>
> >I get the following showing up in my logs:
> >
> >May 17 18:31:17 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MAC> SRC> >84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00
TTL=127
> ID=61103
> >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
> >May 17 18:31:18 www kernel: Shorewall:vpn2fw:ACCEPT:IN=tun0 OUT=
MAC> SRC> >84.234.16.143 DST=84.234.16.233 LEN=48 TOS=0x00 PREC=0x00
TTL=127
> ID=61109
> >DF PROTO=TCP SPT=3822 DPT=27015 WINDOW=65535 RES=0x00 SYN URGP=0
> >
> >... when trying to connect from the interface ''tun0''.
> >
>
> So traffic from 84.234.16.143 enters tun0 destined for 84.234.16.233
>
> >
> >>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
qlen 1000
> >>   link/ether 00:0a:e6:a6:84:9b brd ff:ff:ff:ff:ff:ff
> >>   inet 84.234.16.233/24 brd 84.234.16.255 scope global eth0
> >
>
> Which happens to be the primary IP address of eth0.
>
> >
> >>   inet 84.234.16.145/8 brd 84.255.255.255 scope global eth0:1
> >>   inet 84.234.16.154/24 brd 84.234.16.255 scope global secondary
> eth0:12
> >>   inet 84.234.16.144/24 brd 84.234.16.255 scope global secondary
eth0:2
> >>   inet 84.234.16.145/24 brd 84.234.16.255 scope global secondary
eth0:3
> >>   inet 84.234.16.155/24 brd 84.234.16.255 scope global secondary
> eth0:13
> >>   inet 84.234.16.144/8 brd 84.255.255.255 scope global secondary
eth0:0
> >>   inet6 fe80::20a:e6ff:fea6:849b/64 scope link
> >>      valid_lft forever preferred_lft forever
> >>3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
pfifo_fast qlen
> >>100
> >>   link/[65534]
> >>   inet 84.234.16.145/24 brd 84.234.16.255 scope global tun0
> >
>
> Strangely, tun0 is configured with the same network as eth0!
>
> >
> >>0www~# ip route show
> >>84.234.16.145 dev tun0  scope link
> >>84.234.16.145 dev eth0  scope link  src 84.234.16.145
> >>84.234.16.147 dev tun0  scope link
> >>84.234.16.146 dev tun0  scope link
> >>84.234.16.149 dev tun0  scope link
> >>84.234.16.148 dev tun0  scope link
> >>84.234.16.151 dev tun0  scope link
> >>84.234.16.150 dev tun0  scope link
> >>84.234.16.153 dev tun0  scope link
> >>84.234.16.152 dev tun0  scope link
> >>84.234.16.154 dev tun0  scope link
> >>84.234.16.233 dev eth0  scope link
> >>84.234.16.143 dev tun0  scope link
> >>84.234.16.0/24 dev eth0  proto kernel  scope link  src
84.234.16.233
> >
>
> And the first route to 84.234.16.143 goes out of eth0. So when the
> firewall responds, the response is sent via eth0 rather than via tun0.
>
>
> >>84.234.16.0/24 dev tun0  proto kernel  scope link  src
84.234.16.145
> >>169.254.0.0/16 dev eth0  scope link
> >>84.0.0.0/8 via 84.234.16.1 dev eth0
> >>84.0.0.0/8 dev eth0  proto kernel  scope link  src 84.234.16.145
> >>default via 84.234.16.1 dev eth0
> >>0www~#
> >>
> >
>
> Once again, it''s good to keep in mind that not all connection
problems
> are Shorewall problems. This appears to be a case of a totally
> unworkable IP/VPN/routing configuration.
>
> -Tom
> --
> Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
> Shoreline,     \ http://shorewall.net
> Washington USA  \ teastep@shorewall.net
> PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
>
>
>

Rune Kock

2006-May-19 12:21 UTC

head link

Re: Shorewall and Counter-Strike: Source

Hi Jan

I don''t really understand why you want your clients to be on VPN.  Why
not a direct connection?

If the point is to keep uninvited players from joining, then isn''t
there a simpler way to do that? How about running the server on an
unusual port, and only telling the people you want to join?

If you are looking for stuff to read, there seems to be plenty on
www.openvpn.org.  Really, your problem seems more to be the proper
setup of VPN, rather than Shorewall.

Additionally, Tom has written a guide:
http://www.shorewall.net/OPENVPN.html .  If I guess your intentions
correctly, your setup should look like his road-warrior description.

Another thing: you seem to be using a lot of 84.234.16.xxx addresses.
These are public IP addresses, and you should only use them if they
have been allocated to you.  If you need private IP addresses, you
should use one of the ranges reserved for that, such as
10.xxx.xxx.xxx.


Rune


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Rune Kock

2006-May-19 12:29 UTC

head link

Re: Shorewall and Counter-Strike: Source

RK> I don''t really understand why you want your clients to be on
VPN.  Why
RK> not a direct connection?

Or is it that CS: Source can only be played on LANs.  Then you should
pay attention to Werner''s post:

WM>Not sure if maybe you should rather use bridge mode?
WM>We play a collection of games over bridge mode, including CS:Source.
WM>
WM>With the routing way, broadcasts are not transmitted
WM>over the tunnel, so unless you can specify a server,
WM>I doubt if the clients will be able to connect to it.

RK> If you are looking for stuff to read, there seems to be plenty on
RK> www.openvpn.org.

Sorry, that is www.openvpn.net

There is a special guide to ethernet bridging.


Rune


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Jan Mulders

2006-May-19 12:52 UTC

head link

Re: Shorewall and Counter-Strike: Source

No no, the CS server is in addition to the VPN... I am running the VPN so
paying clients can utilise a full, routed Internet connection, with their
own public IP address, and also connect to my CS server if they wish. Sort
of a "value-added" package if you get what I mean?

Basically, it boils down to exactly the same as a standard proxyarp''ed
client network - I have a LAN with a couple client machines on one side
(tun0), and the Internet on the other (eth0). I also happrn to want to run a
games server so both can access it.

Clients get full public IPs, so they can host servers of their own and
Internet users can connect, but by moving the server down one hop (and away
from the HTTPS proxys clients are using to connect), they lose about 20ms of
latency.

No different from running a standard TCP service on the server.

Hope this clears things up.

Thanks,

Jan

On 19/05/06, Rune Kock <rune.kock@gmail.com>
wrote:>
> RK> I don''t really understand why you want your clients to be
on VPN.  Why
> RK> not a direct connection?
>
> Or is it that CS: Source can only be played on LANs.  Then you should
> pay attention to Werner''s post:
>
> WM>Not sure if maybe you should rather use bridge mode?
> WM>We play a collection of games over bridge mode, including CS:Source.
> WM>
> WM>With the routing way, broadcasts are not transmitted
> WM>over the tunnel, so unless you can specify a server,
> WM>I doubt if the clients will be able to connect to it.
>
> RK> If you are looking for stuff to read, there seems to be plenty on
> RK> www.openvpn.org.
>
> Sorry, that is www.openvpn.net
>
> There is a special guide to ethernet bridging.
>
>
> Rune
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>

Rune Kock

2006-May-19 14:33 UTC

head link

Re: Shorewall and Counter-Strike: Source

> No no, the CS server is in addition to the VPN... I am running the VPN so
> paying clients can utilise a full, routed Internet connection, with their
> own public IP address, and also connect to my CS server if they wish. Sort
> of a "value-added" package if you get what I mean?
Oh, then I''m sorry for making lame comments in my earlier post.

I don''t think that I know enough about routing to help you with this.


Rune


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Shorewall users - May 2006 - Shorewall and Counter-Strike: Source

Shorewall and Counter-Strike: Source

RE: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source

Re: Shorewall and Counter-Strike: Source