On Jul 26, 2011, at 2:42 PM, Das wrote:

> Hi Tom,
> 
> Ok just using only the interfaces, policy and zones here's a dump while
> connected to the vpn with it working with it like this in the policy as I
> mentioned before;
> 
> $FW            net             DROP          ULOG
> #$FW          net             ACCEPT
> $FW             vpn             ACCEPT
> 
> Here's the dump;
> 

Unbelievable -- Shorewall dump output embedded in an HTML/RTF email message. 

> Shorewall 4.4.20.3 Dump at slackware - Tue Jul 26 11:38:50 HST 2011
> 
> Counters reset Tue Jul 26 11:19:27 HST 2011
> 
> 
> Chain OUTPUT (policy DROP 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source
> destination
> 3770  747K fw2net     all  --  *      eth0    0.0.0.0/0
> 0.0.0.0/0
>    0     0 fw2net     all  --  *      wlan0   0.0.0.0/0
> 0.0.0.0/0
> 3690  451K fw2vpn     all  --  *      tun0    0.0.0.0/0
> 0.0.0.0/0
>    0     0 fw2vpn     all  --  *      tap0    0.0.0.0/0
> 0.0.0.0/0
>    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0
> 0.0.0.0/0
>    0     0 Reject     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>    0     0 ULOG       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           ULOG copy_range 0 nlgroup 1 prefix
> `Shorewall:OUTPUT:REJECT:' queue_threshold 1
>    0     0 reject     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           [goto]
> 

Above is the OUTPUT chain. Traffic originating on the firewall and leaving on 
eth0 is sent through chain 'fw2net'.


> Chain fw2net (2 references)
> pkts bytes target     prot opt in     out     source
> destination
>    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           udp dpts:67:68

The above is DHCP.

> 3764  747K ACCEPT     all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           ctstate RELATED,ESTABLISHED

The above just handles packets that are part of a connection

>    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0
> 10.99.99.10
>    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0
> 10.99.99.10         udp dpt:500 ctstate NEW
>    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0
> 0.0.0.0/0

The above are for IPSEC.

>    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0
> 0.0.0.0/0           tcp dpt:51413

Don't know why you want to allow TCP 51413.

>    6   360 Drop       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
>    6   360 ULOG       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0           ULOG copy_range 0 nlgroup 1 prefix
> `Shorewall:fw2net:DROP:' queue_threshold 1
>    6   360 DROP       all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
> 

'Drop' Filters what gets logged by the next rule. ULOG logs it and DROP 
discards it. Note that *no new connections* other than DNS have been 
established since Shorewall was [re]started Tue Jul 26 11:19:27 HST 2011. 

> Conntrack Table (17 out of 65536)
> 
...
> 
> udp      17 175 src=192.168.1.2 dst=94.231.84.80 sport=35711 dport=1194
> src=94.231.84.80 dst=192.168.1.2 sport=1194 dport=35711 [ASSURED] mark=0
> use=2

This connection is your OpenVPN tunnel. That is a fw->net UDP connection to UDP 
port 1194.

> IP Configuration
> 
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>    inet 127.0.0.1/8 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP qlen 1000
>    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
> 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 100
>    inet 10.233.0.148/16 brd 10.233.255.255 scope global tun0
> 
> 

The src address of the tunnel is the IP address of eth0.

> Routing Rules
> 
> 0:    from all lookup local
> 32766:    from all lookup main
> 32767:    from all lookup default
> 
> Table default:
> 
> 
> Table local:
> 
> broadcast 192.168.1.0 dev eth0  proto kernel  scope link  src 192.168.1.2
> broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
> local 192.168.1.2 dev eth0  proto kernel  scope host  src 192.168.1.2
> broadcast 10.233.255.255 dev tun0  proto kernel  scope link  src
> 10.233.0.148
> broadcast 10.233.0.0 dev tun0  proto kernel  scope link  src 10.233.0.148
> local 10.233.0.148 dev tun0  proto kernel  scope host  src 10.233.0.148
> broadcast 192.168.1.255 dev eth0  proto kernel  scope link  src 192.168.1.2
> broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
> local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
> local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
> 
> Table main:
> 
> 94.231.84.80 via 192.168.1.1 dev eth0 <===========================
> 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2  metric
> 202
> 10.233.0.0/16 dev tun0  proto kernel  scope link  src 10.233.0.148
> 127.0.0.0/8 dev lo  scope link
> 0.0.0.0/1 via 10.233.0.1 dev tun0
> 128.0.0.0/1 via 10.233.0.1 dev tun0
> default via 192.168.1.1 dev eth0  metric 202
> 


Which makes sense since the connection would be routed out of eth0 by the first 
route in the main table.

Conclusion. Either:

a) The tunnel was established before Shorewall started.
b) Something is *really* wrong with Netfilter on this system.

-Tom

Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to