Hi All, I just added a second subnet and thought I had read all the relevant FAQ''s and had set things up properly, but a few odd things are happening. ZONES: net Net Internet loc Local Local networks 192.168 loc2 Local Local networks 10.151 ppp PPP PPP Dial-in rw RoadWarriors Road Warriors rw2 RoadWarriors Road Warriors INTERFACES: net eth0 detect norfc1918 - eth1 192.168.168.255,10.151.255.255 multi ppp ppp+ detect rw ipsec+ rw2 tun+ - routeback POLICY: Lots of stuff in here, but I duplicated all entries for the old "loc" with additional ones for "loc2" to handle the same set of allowed connections between the zones. MASQ: eth0 192.168.169.0/24 208.10.57.129 eth0 192.168.168.0/24 208.10.57.129 eth0 10.151.0.0/16 208.10.57.129 HOSTS: loc eth1:192.168.168.0/24 loc2 eth1:10.151.0.0/16 And the basic rules to allow MASQ''d stuff out. I had some restrictions on ports/etc, but for now I''ve just tested it in a more open configuration: ACCEPT loc net tcp ACCEPT loc net udp ACCEPT loc2 net tcp ACCEPT loc2 net udp Everything appears to be working... I do not have direct routes on the machines in each subnet to get to each other, so the rules there are allowing and forwarding the traffic between them. The machines in the new subnet can get to the Internet. However, I get this odd error when I try to use Skype on a machine in the new 10. subnet... No such error from a machine in the original 192. subnet. Mar 31 10:37:02 fw kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:c0:9f:1e:fa:99:00:07:50:cd:a5:80:08:00 SRC=217.165.40.63 DST=208.10.57.129 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=14307 PROTO=UDP SPT=54014 DPT=54046 LEN=28 What have I overlooked? Thanks!! Steve
On Mar 31, 2005, at 10:48 AM, Steven Palm wrote:> I just added a second subnet and thought I had read all the relevant > FAQ''s and had set things up properly, but a few odd things are > happening.. . .> Mar 31 10:37:02 fw kernel: Shorewall:net2all:DROP:IN=eth0 OUT= > MAC=00:c0:9f:1e:fa:99:00:07:50:cd:a5:80:08:00 SRC=217.165.40.63 > DST=208.10.57.129 LEN=48 TOS=0x00 PREC=0x00 TTL=113 ID=14307 PROTO=UDP > SPT=54014 DPT=54046 LEN=28Well, I realize I didn''t put all the right information into the email *AFTER* I sent it... I was running a Shorewall 2.1-something release. Just updated to 2.2.2 And I hadn''t realized it, but I am getting a similar error to the above when I launch Skype from the 192. subnet, but I only get four of them upon initial launch, and then that''s it, and as far as I can tell, everything does seem to be working. Sorry for the noise on the list! Steve
On Thu, 31 Mar 2005, Steven Palm wrote:> And I hadn''t realized it, but I am getting a similar error to the above when > I launch Skype from the 192. subnet, but I only get four of them upon initial > launch, and then that''s it, and as far as I can tell, everything does seem to > be working. > > Sorry for the noise on the list!Some of these "just works" apps need to probe around a bit to determine what type of nat/firewall situation they are dealing with. That''s probably what you are seeing. One question -- you have explicit rules allowing UDP and TCP to the net from your local networks; any reason for not using an ACCEPT policy there? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Mar 31, 2005, at 11:54 AM, Tom Eastep wrote:> One question -- you have explicit rules allowing UDP and TCP to the net > from your local networks; any reason for not using an ACCEPT policy > there?This has migrated from Shorewall 1.2 or thereabouts I think... I haven''t really given it the thorough going over it needs and plan to do that now. I just moved my configs into the new template configs for 2.2.2 so I have the relevant comments at the top and now can re-work it accordingly. I think that for this case in particular, at one point we were restricting who had the capability to go out to the net, and then some people had port-80 access only, no pop3/smtp/etc... Since that time we''ve loosened the restrictions and it probably should be moved to a policy at this point instead of a rule. Thanks!