On 7/24/2014 8:26 PM, [email protected] wrote: > >> In the mean time, I *think* your DNAT rule should be: >> >> DNAT net vpn1:192.168.1.2 tcp 25 S.S.S.S > > Still with > > SERVER (shorewall) > eth0: S.S.S.S > 192.168.0.1 > tun1: 10.0.0.1 > | > | > | > CLIENT (shorewall) > eth0: C.C.C.C > tun1: 10.0.0.2 > eth1: 192.168.1.1 > | > | > | > SMTP > eth0: 192.168.1.2 > > > I've modified zones & rules so that config is now, > > /zones > fw firewall > net ipv4 > vpn1 ipv4 > > /interfaces > net eth0 tcpflags,nosmurfs,routefilter=1,sourceroute=0 > vpn1 tun+ - > > /rules > DNAT net vpn1:192.168.1.2 tcp 25 - S.S.S.S > ACCEPT net vpn1:192.168.1.2 tcp 25
The second rule is redundant -- DNAT entries in the rules file genereate both a DNAT and an ACCEPT iptables rule. > > and the CLIENT shorewall has > > /zones > fw firewall > net ipv4 > lan ipv4 > vpn1 ipv4 > > /interfaces > net eth0 > tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0 > lan eth1 routefilter=1 > vpn1 tun+ - > > /rules > ACCEPT vpn1 lan:192.168.1.2 tcp 25 > > /masq > eth0 192.168.1.2 S.S.S.S tcp 25 > > > > Chain net2vpn1 (1 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate RELATED,ESTABLISHED > 0 0 ~log1 tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 [goto] multiport dports 22,23,1194 > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0 icmptype 8 limit: avg 5/sec burst 100 /* Ping */ > 1 64 ACCEPT tcp -- * * X.X.X.X > 192.168.1.2 multiport dports 25,587 The connection request was accepted. > 0 0 ACCEPT tcp -- * * X.X.X.X > 192.168.1.2 multiport dports 25,587 > 0 0 Drop all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 6 prefix "SW:net2vpn1:DROP " > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > Log (/var/log/shorewall/shorewall) > > 2014-07-24T18:33:37.305475-07:00 server SW:[TEST]:DNAT IN=eth0 OUT= > SRC=X.X.X.X DST=S.S.S.S LEN=64 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP > SPT=55981 DPT=25 WINDOW=32768 RES=0x00 SYN URGP=0 > That log message was generated out of the log0 chain below: > NAT Table > > Chain PREROUTING (policy ACCEPT 98 packets, 5725 bytes) > pkts bytes target prot opt in out source > destination > 103 6045 net_dnat all -- eth0 * 0.0.0.0/0 > 0.0.0.0/0 > > Chain INPUT (policy ACCEPT 61 packets, 3622 bytes) > pkts bytes target prot opt in out source > destination > > Chain OUTPUT (policy ACCEPT 57 packets, 3476 bytes) > pkts bytes target prot opt in out source > destination > > Chain POSTROUTING (policy ACCEPT 62 packets, 3796 bytes) > pkts bytes target prot opt in out source > destination > 6 404 tun+_masq all -- * tun+ 0.0.0.0/0 > 0.0.0.0/0 > > Chain net_dnat (1 references) > pkts bytes target prot opt in out source > destination > 5 320 ~log0 tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 [goto] multiport dports 25,587 Packets are matching this rule > 0 0 ~log0 tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 [goto] multiport dports 25,587 > > Chain tun+_masq (1 references) > pkts bytes target prot opt in out source > destination > 0 0 SNAT tcp -- * tun1 10.0.0.1 > 0.0.0.0/0 multiport dports 25,587 to:S.S.S.S > > Chain ~log0 (2 references) > pkts bytes target prot opt in out source > destination > 5 320 LOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 LOG flags 0 level 6 prefix "SW:[TEST]:DNAT " > 5 320 DNAT all -- * * 0.0.0.0/0 > 0.0.0.0/0 to:192.168.1.2 And are being DNATted. > Conntrack Table (36 out of 65536) > > ipv4 2 tcp 6 431921 ESTABLISHED src=C.C.C.C dst=S.S.S.S > sport=46051 dport=22 src=S.S.S.S dst=C.C.C.C sport=22 dport=46051 [ASSURED] > mark=0 zone=0 use=2 > ipv4 2 udp 17 179 src=C.C.C.C dst=S.S.S.S sport=1194 > dport=1194 src=S.S.S.S dst=C.C.C.C sport=1194 dport=1194 [ASSURED] mark=0 > zone=0 use=2 > ipv4 2 tcp 6 113 SYN_SENT src=X.X.X.X dst=S.S.S.S sport=55981 > dport=25 [UNREPLIED] src=192.168.1.2 dst=X.X.X.X sport=25 dport=55981 mark=0 > zone=0 use=2 > The request has been sent on to 192.168.1.2 which has not responded. ... > > Routing Rules > > 0: from all lookup local > 32766: from all lookup main > 32767: from all lookup default > > Table default: > > > Table local: > > local S.S.S.95 dev eth0 proto kernel scope host src S.S.S.S > local S.S.S.S dev eth0 proto kernel scope host src S.S.S.S > local S.S.S.S dev eth0 proto kernel scope host src S.S.S.S > local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1 > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > local 10.0.0.1 dev tun1 proto kernel scope host src 10.0.0.1 > local 192.168.0.1 dev eth0 proto kernel scope host src 192.168.0.1 > broadcast S.S.S.255 dev eth0 proto kernel scope link src S.S.S.S > broadcast S.S.S.0 dev eth0 proto kernel scope link src S.S.S.S > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 > broadcast 10.0.0.255 dev tun1 proto kernel scope link src 10.0.0.1 > broadcast 10.0.0.0 dev tun1 proto kernel scope link src 10.0.0.1 > broadcast 192.168.0.255 dev eth0 proto kernel scope link src 192.168.0.1 > broadcast 192.168.0.0 dev eth0 proto kernel scope link src 192.168.0.1 > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > > Table main: > > S.S.S.0/24 dev eth0 proto kernel scope link src S.S.S.S > 10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1 > 192.168.1.0/24 via 10.0.0.2 dev tun1 192.168.1.0/24 is correctly being routed through tun1. > > >>> Post the /tmp/status.txt file as an attachment compressed with gzip >>> or bzip2. > > What generates that "status.txt" file? I can find no trace of it. > >>> Describe where you are trying to make the connection from (IP >>> address) and what host (IP address) you are trying to connect to. > > ... think I got that already. > >> If everything seems to be correct according to these tests but the >> connection doesn't work, it may be that your ISP is blocking SYN,ACK >> responses. >> This technique allows your ISP to detect when you are running a server >> (usually in violation of your service agreement) and to stop connections to >> that server from being established. > > Everything's on 'biz class' staticIP. servers are perfectly fine. The configuration on the SERVER is now correct and the issue is on the CLIENT. What is the shorewall.conf setting for ROUTE_FILTER on the CLIENT? If it is 'Yes' then set it to 'No' and restart Shorewall. If it doesn't work after that change, then please run the test again but this time forward a dump taken on the CLIENT. Thanks, -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
