Hello, I tried to open up http acces from one internal segment of the network to another (from the office segment to what we call the public segment). I tried to do so using the answers in faq 1d. our rule looks like this: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT office public:192.168.2.161 tcp 80 - 194.109.134.194 But it does not work, What to do? also I need to open ftp and ssh ports from office segment to the public segment. all to reach a testserver stated in the public segment. can someone help me out on this? Fons Hof netwerkbeheer Theater de Balie f.hof@balie.nl +31653399910
Fons Hof wrote:> I tried to open up http acces from one internal segment of the network to another (from the office segment to > what we call the public segment). I tried to do so using the answers in faq 1d. > our rule looks like this: > > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL > # PORT PORT(S) DEST > DNAT office public:192.168.2.161 tcp 80 - 194.109.134.194 > > But it does not work, What to do?You might start with the DNAT trouble-shooting tips in FAQs 1a and 1b. The names of the zones will have changed but the basic trouble-shooting technique is the same.> > also I need to open ftp and ssh ports from office segment to the public segment. all to reach a testserver > stated in the public segment. > > can someone help me out on this?Only if you can provide us with more details. See http://www.shorewall.net/support.htm -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
Hello,> Fons Hof wrote: > > > I tried to open up http acces from one internal segment of the network to another (from the office segment to > > what we call the public segment). I tried to do so using the answers in faq 1d. > > our rule looks like this: > > > > #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL > > # PORT PORT(S) DEST > > DNAT office public:192.168.2.161 tcp 80 - 194.109.134.194 > > > > But it does not work, What to do? > > You might start with the DNAT trouble-shooting tips in FAQs 1a and 1b. The names > of the zones will have changed but the basic trouble-shooting technique is the same.I followed the troubleshooting tips in the FAQ. but this doesn''t help me out. still the connection from the office segment to the public segment doesn''t work. the route to the gateway is correctly set on the destination server (gateway: 192.168.2.1 is eth1 on shorewall) from a another outside connection there is no problem reaching the server. showing the nat there is no traffic to the destination server after trying to reach the server chain office_dnat (1 references) pkts bytes target prot opt in out source destination 0 0 DNAT tcp -- * * 0.0.0.0/0 194.109.134.194 tcp dpt:80 to:192.168.2.161 I hoop you can see what I did wrong> > > > > also I need to open ftp and ssh ports from office segment to the public segment. all to reach a testserver > > stated in the public segment. > > > > can someone help me out on this? > > Only if you can provide us with more details. See > http://www.shorewall.net/support.htmSo here are details on our shorewall version shorewall version 2.2.5 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 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:0e:0c:a8:71:5c brd ff:ff:ff:ff:ff:ff inet 10.0.2.1/24 brd 10.0.2.255 scope global eth0 inet6fe80::20e:cff:fea8:715c/64 scope link Valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0e:0c:a8:71:5d brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global eth1 inet6 fe80::20e:cff:fea8:715d/64 scope link Valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:14:22:22:f6:79 brd ff:ff:ff:ff:ff:ff inet 10.0.10.225/27 brd 10.0.10.255 scope global eth2 inet6 fe80::214:22ff:fe22:f679/64 scope link Valid_lft forever preferred_lft forever 5: eth3: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:14:22:22:f6:7a brd ff:ff:ff:ff:ff:ff inet 194.109.134.194/27 brd 194.109.134.223 scope global eth3 inet 194.109.134.226/26 brd 194.109.134.255 scope global eth3:0 inet6 fe80::214:22ff:fe22:f679/64 scope link Valid_lft forever preferred_lft forever 6: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 note: eth0 is office network eth1 is public for open internet access and our wireless station eth2 is DMZ eth3 is our default internet connection eth3:0 is a virtual internet connection ip route show 10.0.10.224/27 dev eth2 proto kernel scope link src 10.0.10.225 194.109.134.192/27 dev eth3 proto kernel scope link src 194.109.134.194 194.109.134.192/26 dev eth3 proto kernel scope link src 194.109.134.226 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.1 default via 194.109.134.193 dev eth3 src 194.109.134.226 default via 194.109.134.193 dev eth3 I hope this information will help you to answer my question> > -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 > >Fons Hof netwerkbeheer Theater de Balie f.hof@balie.nl +31653399910
Fons Hof wrote:> Hello, > > >> Fons Hof wrote: >> >>> I tried to open up http acces from one internal segment of the network to another (from the office segment to >>> what we call the public segment). I tried to do so using the answers in faq 1d. >>> our rule looks like this: >>> >>> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL >>> # PORT PORT(S) DEST >>> DNAT office public:192.168.2.161 tcp 80 - 194.109.134.194 >>> >>> But it does not work, What to do? >> You might start with the DNAT trouble-shooting tips in FAQs 1a and 1b. The names >> of the zones will have changed but the basic trouble-shooting technique is the same. > > I followed the troubleshooting tips in the FAQ. but this doesn''t help me out. still the connection from the office > segment to the public segment doesn''t work. the route to the gateway is correctly set on the destination server > (gateway: 192.168.2.1 is eth1 on shorewall) from a another outside connection there is no problem reaching the > server. > showing the nat there is no traffic to the destination server after trying to reach the server > chain office_dnat (1 references) > pkts bytes target prot opt in out source destination > 0 0 DNAT tcp -- * * 0.0.0.0/0 194.109.134.194 tcp dpt:80 > to:192.168.2.161 >The above output shows that no traffic is matching the DNAT rule. So either: a) The connection requests are never reaching the Shorewall box (or no connections were attempted since the last "shorewall [re]start" or "shorwall reset"). That would mean most likely that from the client, the route to 194.109.134.194 doesn''t go through the Shorewall box. b) The connection requests are reaching the Shorewall box through an interface other than the one(s) associated with the office zone. c) The connection requests are not addressed to 194.109.134.194, don''t use the TCP protocol or don''t have destination port 80.> > So here are details on our shorewall version > > shorewall version 2.2.5 >That version of Shorewall is no longer supported. But if you persist in running it, please use the Shorewall 2.x Documentation and support information on the web site. Beware that if you upgrade to a later Shorwall version, you will have to rename your zones as ''office'' has 6 characters. The Documentation has always indicated that the names have a maximum length of 5 but that wasn''t enforced in the older versions of the code -- it is enforced in the current version though.> > > I hope this information will help you to answer my question >It doesn''t. The 2.x support guide requests that you: a) shorewall reset b) Try the connection that is giving your problems c) shorewall status > /tmp/status.txt d) Attach the /tmp/status.txt file to your problem report as an attachment. e) Your post should describe the ip address of the client and the ip address that the connection was attempted to. -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