Search Results

Search found 188 results on 8 pages for 'syn'.

Page 2/8 | < Previous Page | 1 2 3 4 5 6 7 8  | Next Page >

  • Packets marked by iptables only sent to the correct routing table sometimes

    - by cookiecaper
    I am trying to route packets generated by a specific user out over a VPN. I have this configuration: $ sudo iptables -S -t nat -P PREROUTING ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A POSTROUTING -o tun0 -j MASQUERADE $ sudo iptables -S -t mangle -P PREROUTING ACCEPT -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A OUTPUT -m owner --uid-owner guy -j MARK --set-xmark 0xb/0xffffffff $ sudo ip rule show 0: from all lookup local 32765: from all fwmark 0xb lookup 11 32766: from all lookup main 32767: from all lookup default $ sudo ip route show table 11 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 10.8.0.6 dev tun0 scope link 10.8.0.1 via 10.8.0.5 dev tun0 0.0.0.0/1 via 10.8.0.5 dev tun0 $ sudo iptables -S -t raw -P PREROUTING ACCEPT -P OUTPUT ACCEPT -A OUTPUT -m owner --uid-owner guy -j TRACE -A OUTPUT -p tcp -m tcp --dport 80 -j TRACE It seems that some sites work fine and use the VPN, but others don't and fall back to the normal interface. This is bad. This is a packet trace that used VPN: Oct 27 00:24:28 agent kernel: [612979.976052] TRACE: raw:OUTPUT:rule:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976105] TRACE: raw:OUTPUT:policy:3 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976164] TRACE: mangle:OUTPUT:rule:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976210] TRACE: mangle:OUTPUT:policy:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976269] TRACE: nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976320] TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976367] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=tun0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976414] TRACE: nat:POSTROUTING:rule:1 IN= OUT=tun0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb and this is one that didn't: Oct 27 00:22:41 agent kernel: [612873.662559] TRACE: raw:OUTPUT:rule:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662609] TRACE: raw:OUTPUT:policy:3 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662664] TRACE: mangle:OUTPUT:rule:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662709] TRACE: mangle:OUTPUT:policy:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662761] TRACE: nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662808] TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662855] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb I have already tried "ip route flush cache", to no avail. I do not know why the first packet goes through the correct routing table, and the second doesn't. Both are marked. Once again, I do not want ALL packets system-wide to go through the VPN, I only want packets from a specific user (UID=999) to go through the VPN. I am testing ipchicken.com and walmart.com via links, from the same user, same shell. walmart.com appears to use the VPN; ipchicken.com does not. Any help appreciated. Will send 0.5 bitcoins to answerer who makes this fixed.

    Read the article

  • tcptrack shows SYN_SENT connections, does that mean the SYN package reached the server?

    - by xpu
    our server suffered a serious connection timeout problem, so we track tcp connection with tcptrack we found out that, if the client started to connect to the server, tcptrack shows the connection, but in SYN_SENT status, and netstat -nat shows nothing. (tcptrack & netstat all runs on the server) does this mean the syn request reached the server? and no syn/ack was sent back? why the tcptrack could report this connection but netstat could not? what could be the problem that a general apache could not establish a connection with the client? i did a bench test using ab in the same intranet, to the specified NIC, it handled 10000 concurrent connection and 400000 requests ok ps: this doesn't happen every time, but did happened a lot pps: is there any good tools to trace where the tcp connection was lost?

    Read the article

  • Block ip for long time

    - by Tiziano Dan
    This question is about a iptables, I wanna to know how can I block these ip for 1hour and not only a little time.. because they make to many sql requests, I'm using it for block but it's not enough because there's anyway 100k ip who attack then too much requests for sql server. iptables -N SYN-LIMIT iptables -A SYN-LIMIT -m hashlimit --hashlimit 8/second --hashlimit-mode srcip --hashlimit-name SYN-LIMIT -j RETURN iptables -A SYN-LIMIT -j DROP iptables -I INPUT -p tcp --dport 80 --syn -j SYN-LIMIT iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 6 -j REJECT --reject-with tcp-reset How can I make the same but block IP for long time ? (Not manually !)

    Read the article

  • Router 2wire, Slackware desktop in DMZ mode, iptables policy aginst ping, but still pingable

    - by user135501
    I'm in DMZ mode, so I'm firewalling myself, stealthy all ok, but I get faulty test results from Shields Up that there are pings. Yesterday I couldn't make a connection to game servers work, because ping block was enabled (on the router). I disabled it, but this persists even due to my firewall. What is the connection between me and my router in DMZ mode (for my machine, there is bunch of others too behind router firewall)? When it allows router affecting if I'm pingable or not and if router has setting not blocking ping, rules in my iptables for this scenario do not work. Please ignore commented rules, I do uncomment them as I want. These two should do the job right? iptables -A INPUT -p icmp --icmp-type echo-request -j DROP echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all Here are my iptables: #!/bin/sh # Begin /bin/firewall-start # Insert connection-tracking modules (not needed if built into the kernel). #modprobe ip_tables #modprobe iptable_filter #modprobe ip_conntrack #modprobe ip_conntrack_ftp #modprobe ipt_state #modprobe ipt_LOG # allow local-only connections iptables -A INPUT -i lo -j ACCEPT # free output on any interface to any ip for any service # (equal to -P ACCEPT) iptables -A OUTPUT -j ACCEPT # permit answers on already established connections # and permit new connections related to established ones (eg active-ftp) iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #Gamespy&NWN #iptables -A INPUT -p tcp -m tcp -m multiport --ports 5120:5129 -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 6667 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 28910 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29900 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29901 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29920 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p udp -m udp -m multiport --ports 5120:5129 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 6500 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 27900 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 27901 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 29910 -j ACCEPT # Log everything else: What's Windows' latest exploitable vulnerability? iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT" # set a sane policy: everything not accepted > /dev/null iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP iptables -A INPUT -p icmp --icmp-type echo-request -j DROP # be verbose on dynamic ip-addresses (not needed in case of static IP) echo 2 > /proc/sys/net/ipv4/ip_dynaddr # disable ExplicitCongestionNotification - too many routers are still # ignorant echo 0 > /proc/sys/net/ipv4/tcp_ecn #ping death echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all # If you are frequently accessing ftp-servers or enjoy chatting you might # notice certain delays because some implementations of these daemons have # the feature of querying an identd on your box for your username for # logging. Although there's really no harm in this, having an identd # running is not recommended because some implementations are known to be # vulnerable. # To avoid these delays you could reject the requests with a 'tcp-reset': #iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset #iptables -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT # To log and drop invalid packets, mostly harmless packets that came in # after netfilter's timeout, sometimes scans: #iptables -I INPUT 1 -p tcp -m state --state INVALID -j LOG --log-prefix \ "FIREWALL:INVALID" #iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP # End /bin/firewall-start

    Read the article

  • Router 2wire, Slackware desktop in DMZ mode, iptables policy aginst ping, but still pingable

    - by skriatok
    I'm in DMZ mode, so I'm firewalling myself, stealthy all ok, but I get faulty test results from Shields Up that there are pings. Yesterday I couldn't make a connection to game servers work, because ping block was enabled (on the router). I disabled it, but this persists even due to my firewall. What is the connection between me and my router in DMZ mode (for my machine, there is bunch of others too behind router firewall)? When it allows router affecting if I'm pingable or not and if router has setting not blocking ping, rules in my iptables for this scenario do not work. Please ignore commented rules, I do uncomment them as I want. These two should do the job right? iptables -A INPUT -p icmp --icmp-type echo-request -j DROP echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all Here are my iptables: #!/bin/sh # Begin /bin/firewall-start # Insert connection-tracking modules (not needed if built into the kernel). #modprobe ip_tables #modprobe iptable_filter #modprobe ip_conntrack #modprobe ip_conntrack_ftp #modprobe ipt_state #modprobe ipt_LOG # allow local-only connections iptables -A INPUT -i lo -j ACCEPT # free output on any interface to any ip for any service # (equal to -P ACCEPT) iptables -A OUTPUT -j ACCEPT # permit answers on already established connections # and permit new connections related to established ones (eg active-ftp) iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT #Gamespy&NWN #iptables -A INPUT -p tcp -m tcp -m multiport --ports 5120:5129 -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 6667 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 28910 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29900 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29901 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p tcp -m tcp --dport 29920 --tcp-flags SYN,RST,ACK SYN -j ACCEPT #iptables -A INPUT -p udp -m udp -m multiport --ports 5120:5129 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 6500 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 27900 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 27901 -j ACCEPT #iptables -A INPUT -p udp -m udp --dport 29910 -j ACCEPT # Log everything else: What's Windows' latest exploitable vulnerability? iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT" # set a sane policy: everything not accepted > /dev/null iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT DROP iptables -A INPUT -p icmp --icmp-type echo-request -j DROP # be verbose on dynamic ip-addresses (not needed in case of static IP) echo 2 > /proc/sys/net/ipv4/ip_dynaddr # disable ExplicitCongestionNotification - too many routers are still # ignorant echo 0 > /proc/sys/net/ipv4/tcp_ecn #ping death echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all # If you are frequently accessing ftp-servers or enjoy chatting you might # notice certain delays because some implementations of these daemons have # the feature of querying an identd on your box for your username for # logging. Although there's really no harm in this, having an identd # running is not recommended because some implementations are known to be # vulnerable. # To avoid these delays you could reject the requests with a 'tcp-reset': #iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset #iptables -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT # To log and drop invalid packets, mostly harmless packets that came in # after netfilter's timeout, sometimes scans: #iptables -I INPUT 1 -p tcp -m state --state INVALID -j LOG --log-prefix \ "FIREWALL:INVALID" #iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP # End /bin/firewall-start Active ruleset: bash-4.1# iptables -L -n -v Chain INPUT (policy DROP 38 packets, 2228 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 844 542K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 38 2228 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT' 0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 38 2228 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT' Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 1158 111K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Active ruleset: (after editing iptables into below sugested form) bash-4.1# iptables -L -n -v Chain INPUT (policy DROP 2567 packets, 172K bytes) pkts bytes target prot opt in out source destination 49 4157 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 412K 441M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2567 172K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT' 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 312K packets, 25M bytes) pkts bytes target prot opt in out source destination ping and syslog simultaneous screenshots from phone (pinger) and from laptop (being pinged) http://dl.dropbox.com/u/4160051/slckwr/pingfrom%20mobile.jpg http://dl.dropbox.com/u/4160051/slckwr/tailsyslog.jpg

    Read the article

  • Best way to syn a file between 2 or more drives?

    - by jasondavis
    I have a special file that I edit daily, it is somewhat like a large text file but a little more to it then that. I have a copy on my main desktop and a copy of the file on a USB drive as well. I would like a way to open up either file (from the USB drive or from my desktop drive) and be able to edit and save the file and have it stay updated on both drives. What is a lightweight and easy method of doing this? I do not need anything fancy

    Read the article

  • getting an onclick event to a select option using js

    - by Vadim.G
    i am having a very frustrating problem. I have this code which filters out my results and inputs them into a select box var syn = <?=json_encode($syn)?>; function filterByCity() { var e = document.getElementById("city_filter"); var city = e.options[e.selectedIndex].value; var selectOptions = document.getElementById('syn_list'); selectOptions.options.length = 0; for (i = 0; i < syn.length; i++) { if (city == syn[i]['city'] || city == 'all') { selectOptions.options[selectOptions.options.length] = new Option(syn[i]['name'], syn[i]['id'] + '" onclick="updateTxtContent(\'' + syn[i]['id'] + '\')'); } } } as you might see i am adding a onclick listener to every select "option" which look great in the source code of the page itself but if i copy it into an edit i notice this my problem is that the "updateTxtContent()" function is not called. <select size="10" name="syn_list" id="syn_list" class="span12" dir="rtl" style="text-align:right;"> <option value="13&quot; onclick=&quot;updateTxtContent('13')">option a</option> <option value="14&quot; onclick=&quot;updateTxtContent('14')">option b</option> obviously there should be a better way to do this that i am not aware of.

    Read the article

  • iptables issue on plesk

    - by Fred Rufin
    i don't know how to open a specific port (rtmp=1935) on my CentOS server using Plesk or itables. I created new rules for port 1935 i/o using Plesk/Modules/Firewall but this doesn't work. Nmap scanning tells me this : 1935/tcp filtered rtmp . So i decided to have look at my iptable using SSH (iptables -L), and iptables seems to contain my rules (tcp spt:macromedia-fcs): Chain INPUT (policy DROP) target prot opt source destination VZ_INPUT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination VZ_FORWARD all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination VZ_OUTPUT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN reject-with tcp-reset DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere Chain VZ_FORWARD (1 references) target prot opt source destination Chain VZ_INPUT (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- anywhere anywhere tcp dpt:smtp ACCEPT tcp -- anywhere anywhere tcp dpt:pop3 ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpts:filenet-tms:65535 ACCEPT udp -- anywhere anywhere udp dpts:filenet-tms:65535 ACCEPT tcp -- anywhere anywhere tcp dpt:cddbp-alt ACCEPT tcp -- anywhere anywhere tcp dpt:pcsync-https ACCEPT tcp -- localhost.localdomain localhost.localdomain ACCEPT tcp -- anywhere anywhere tcp dpt:macromedia-fcs ACCEPT udp -- localhost.localdomain localhost.localdomain Chain VZ_OUTPUT (1 references) target prot opt source destination ACCEPT tcp -- anywhere anywhere tcp spt:http ACCEPT tcp -- anywhere anywhere tcp spt:ssh ACCEPT tcp -- anywhere anywhere tcp spt:smtp ACCEPT tcp -- anywhere anywhere tcp spt:pop3 ACCEPT tcp -- anywhere anywhere tcp spt:domain ACCEPT udp -- anywhere anywhere udp spt:domain ACCEPT tcp -- anywhere anywhere ACCEPT udp -- anywhere anywhere ACCEPT tcp -- anywhere anywhere tcp spt:cddbp-alt ACCEPT tcp -- anywhere anywhere tcp spt:pcsync-https ACCEPT tcp -- localhost.localdomain localhost.localdomain ACCEPT tcp -- anywhere anywhere tcp spt:macromedia-fcs ACCEPT udp -- localhost.localdomain localhost.localdomain My rules seems to be OK but there is no connection to 1935 port using a browser. I can connect to this port with SSH (typing "wget myServerIP:1935") but maybe this is because it is an SSH tunelling ? I don't know how to do.

    Read the article

  • Iptables blocking mysql port 3306

    - by valmar
    I got a Tomcat server running a web application that must access a mysql server via Hibernate on the same machine. So, I added a rule for port 3306 to my iptables script but tomcat cannot connect to the mysql server for some reason. I need to reset all iptables rules - Then tomcat can connect to the mysql server again. All the other iptables rules work perfectly though. What's wrong? Here is my script: iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 24 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp -s localhost --dport 8009 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp -d localhost --dport 8009 -j ACCEPT iptables -A INPUT -p tcp -s localhost --dport 3306 -j ACCEPT iptables -A OUTPUT -p tcp -d localhost --dport 3306 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 25 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT iptables -A INPUT -p tcp --dport 587 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT iptables -A INPUT -p tcp --dport 465 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 465 -j ACCEPT iptables -A INPUT -p tcp --dport 110 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 110 -j ACCEPT iptables -A INPUT -p tcp --dport 995 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 995 -j ACCEPT iptables -A INPUT -p tcp --dport 143 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 143 -j ACCEPT iptables -A INPUT -p tcp --dport 993 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 993 -j ACCEPT iptables -A INPUT -j DROP My /etc/hosts file: # nameserver config # IPv4 127.0.0.1 localhost 46.4.7.93 mydomain.com 46.4.7.93 Ubuntu-1004-lucid-64-minimal 46.4.7.93 horst # IPv6 ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts Having a look into the iptables logs, gives me this: Jun 22 16:52:43 Ubuntu-1004-lucid-64-minimal kernel: [ 435.111780] denied-input IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52432 DF PROTO=TCP SPT=56108 DPT=8009 WINDOW=32792 RES=0x00 SYN URGP=0 Jun 22 16:52:46 Ubuntu-1004-lucid-64-minimal kernel: [ 438.110555] denied-input IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52433 DF PROTO=TCP SPT=56108 DPT=8009 WINDOW=32792 RES=0x00 SYN URGP=0 Jun 22 16:52:46 Ubuntu-1004-lucid-64-minimal kernel: [ 438.231954] denied-input IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48020 DF PROTO=TCP SPT=56109 DPT=8009 WINDOW=32792 RES=0x00 SYN URGP=0 Jun 22 16:52:49 Ubuntu-1004-lucid-64-minimal kernel: [ 441.229778] denied-input IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48021 DF PROTO=TCP SPT=56109 DPT=8009 WINDOW=32792 RES=0x00 SYN URGP=0 Jun 22 16:53:57 Ubuntu-1004-lucid-64-minimal kernel: [ 508.731839] denied-input IN=eth0 OUT= MAC=6c:62:6d:85:bf:0e:00:26:88:75:dc:01:08:00 SRC=78.92.97.67 DST=46.4.7.93 LEN=64 TOS=0x00 PREC=0x00 TTL=122 ID=23053 DF PROTO=TCP SPT=1672 DPT=445 WINDOW=65535 RES=0x00 SYN URGP=0 Jun 22 16:53:59 Ubuntu-1004-lucid-64-minimal kernel: [ 511.625038] denied-input IN=eth0 OUT= MAC=6c:62:6d:85:bf:0e:00:26:88:75:dc:01:08:00 SRC=78.92.97.67 DST=46.4.7.93 LEN=64 TOS=0x00 PREC=0x00 TTL=122 ID=23547 DF PROTO=TCP SPT=1672 DPT=445 WINDOW=65535 RES=0x00 SYN URGP=0 Jun 22 16:54:22 Ubuntu-1004-lucid-64-minimal kernel: [ 533.981995] denied-input IN=eth0 OUT= MAC=6c:62:6d:85:bf:0e:00:26:88:75:dc:01:08:00 SRC=27.254.39.16 DST=46.4.7.93 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=6549 PROTO=TCP SPT=6005 DPT=33796 WINDOW=64240 RES=0x00 ACK SYN URGP=0 Jun 22 16:54:44 Ubuntu-1004-lucid-64-minimal kernel: [ 556.297038] denied-input IN=eth0 OUT= MAC=6c:62:6d:85:bf:0e:00:26:88:75:dc:01:08:00 SRC=94.78.93.41 DST=46.4.7.93 LEN=40 TOS=0x00 PREC=0x00 TTL=52 ID=7712 PROTO=TCP SPT=57598 DPT=445 WINDOW=512 RES=0x00 SYN URGP=0

    Read the article

  • iptables - quick safety eval & limit max conns over time

    - by Peter Hanneman
    Working on locking down a *nix server box with some fancy iptable(v1.4.4) rules. I'm approaching the matter with a "paranoid, everyone's out to get me" style, not necessarily because I expect the box to be a hacker magnet but rather just for the sake of learning iptables and *nix security more throughly. Everything is well commented - so if anyone sees something I missed please let me know! The *nat table's "--to-ports" point to the only ports with actively listening services. (aside from pings) Layer 2 apps listen exclusively on chmod'ed sockets bridged by one of the layer 1 daemons. Layers 3+ inherit from layer 2 in a similar fashion. The two lines giving me grief are commented out at the very bottom of the *filter rules. The first line runs fine but it's all or nothing. :) Many thanks, Peter H. *nat #Flush previous rules, chains and counters for the 'nat' table -F -X -Z #Redirect traffic to alternate internal ports -I PREROUTING --src 0/0 -p tcp --dport 80 -j REDIRECT --to-ports 8080 -I PREROUTING --src 0/0 -p tcp --dport 443 -j REDIRECT --to-ports 8443 -I PREROUTING --src 0/0 -p udp --dport 53 -j REDIRECT --to-ports 8053 -I PREROUTING --src 0/0 -p tcp --dport 9022 -j REDIRECT --to-ports 8022 COMMIT *filter #Flush previous settings, chains and counters for the 'filter' table -F -X -Z #Set default behavior for all connections and protocols -P INPUT DROP -P OUTPUT DROP -A FORWARD -j DROP #Only accept loopback traffic originating from the local NIC -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP #Accept all outgoing non-fragmented traffic having a valid state -A OUTPUT ! -f -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT #Drop fragmented incoming packets (Not always malicious - acceptable for use now) -A INPUT -f -j DROP #Allow ping requests rate limited to one per second (burst ensures reliable results for high latency connections) -A INPUT -p icmp --icmp-type 8 -m limit --limit 1/sec --limit-burst 2 -j ACCEPT #Declaration of custom chains -N INSPECT_TCP_FLAGS -N INSPECT_STATE -N INSPECT #Drop incoming tcp connections with invalid tcp-flags -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ALL ALL -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ALL NONE -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ACK,FIN FIN -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ACK,PSH PSH -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ACK,URG URG -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags FIN,RST FIN,RST -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags SYN,RST SYN,RST -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP -A INSPECT_TCP_FLAGS -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP #Accept incoming traffic having either an established or related state -A INSPECT_STATE -m state --state ESTABLISHED,RELATED -j ACCEPT #Drop new incoming tcp connections if they aren't SYN packets -A INSPECT_STATE -m state --state NEW -p tcp ! --syn -j DROP #Drop incoming traffic with invalid states -A INSPECT_STATE -m state --state INVALID -j DROP #INSPECT chain definition -A INSPECT -p tcp -j INSPECT_TCP_FLAGS -A INSPECT -j INSPECT_STATE #Route incoming traffic through the INSPECT chain -A INPUT -j INSPECT #Accept redirected HTTP traffic via HA reverse proxy -A INPUT -p tcp --dport 8080 -j ACCEPT #Accept redirected HTTPS traffic via STUNNEL SSH gateway (As well as tunneled HTTPS traffic destine for other services) -A INPUT -p tcp --dport 8443 -j ACCEPT #Accept redirected DNS traffic for NSD authoritative nameserver -A INPUT -p udp --dport 8053 -j ACCEPT #Accept redirected SSH traffic for OpenSSH server #Temp solution: -A INPUT -p tcp --dport 8022 -j ACCEPT #Ideal solution: #Limit new ssh connections to max 10 per 10 minutes while allowing an "unlimited" (or better reasonably limited?) number of established connections. #-A INPUT -p tcp --dport 8022 --state NEW,ESTABLISHED -m recent --set -j ACCEPT #-A INPUT -p tcp --dport 8022 --state NEW -m recent --update --seconds 600 --hitcount 11 -j DROP COMMIT *mangle #Flush previous rules, chains and counters in the 'mangle' table -F -X -Z COMMIT

    Read the article

  • IP Tables won't save the rule.

    - by ArchUser
    Hello, I'm using ArchLinux and I have an IP tables rule that I know works (from my other server), and it's in /etc/iptables/iptables.rules, it's the only rule set in that directory. I run, /etc/rc.d/iptables save, then /etc/rc.d/iptables/restart, but when I do "iptables --list", I get ACCEPTs on INPUT,FORWARD & OUTPUT. # Generated by iptables-save v1.4.8 on Sat Jan 8 18:42:50 2011 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [216:14865] :BRUTEGUARD - [0:0] :interfaces - [0:0] :open - [0:0] -A INPUT -p icmp -m icmp --icmp-type 18 -j DROP -A INPUT -p icmp -m icmp --icmp-type 17 -j DROP -A INPUT -p icmp -m icmp --icmp-type 10 -j DROP -A INPUT -p icmp -m icmp --icmp-type 9 -j DROP -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP -A INPUT -p icmp -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -j interfaces -A INPUT -j open -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP -A INPUT -f -j DROP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP -A INPUT -i eth+ -p icmp -m icmp --icmp-type 8 -j DROP -A BRUTEGUARD -m recent --set --name BF --rsource -A BRUTEGUARD -m recent --update --seconds 600 --hitcount 20 --name BF --rsource -j LOG --log-prefix "[BRUTEFORCE ATTEMPT] " --log-level 6 -A BRUTEGUARD -m recent --update --seconds 600 --hitcount 20 --name BF --rsource -j DROP -A interfaces -i lo -j ACCEPT -A open -p tcp -m tcp --dport 80 -j ACCEPT -A open -p tcp -m tcp --dport 10011 -j ACCEPT -A open -p udp -m udp --dport 9987 -j ACCEPT -A open -p tcp -m tcp --dport 30033 -j ACCEPT -A open -p tcp -m tcp --dport 8000 -j ACCEPT -A open -p tcp -m tcp --dport 8001 -j ACCEPT -A open -s 76.119.125.61 -p tcp -m tcp --dport 21 -j ACCEPT -A open -s 76.119.125.61 -p tcp -m tcp --dport 3306 -j ACCEPT -A open -p tcp -m tcp --dport 22 -j BRUTEGUARD -A open -s 76.119.125.61 -p tcp -m tcp --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT COMMIT # Completed on Sat Jan 8 18:42:50 2011

    Read the article

  • fail2ban log parsing too slow on Raspberry Pi - options? [migrated]

    - by Gordon Morehouse
    I'm running fail2ban on a Raspberry Pi at 950MHz which I cannot overclock further. The Pi is occasionally subject to SYN floods on particular ports. I've set up iptables to throttle the rate of SYNs on the port of interest; when the throttle limits are exceeded, hosts which send SYNs are dropped into the REJECT chain and the particular SYN packet which exceeded the limit is logged. fail2ban then watches for these logged SYNs and, after seeing a few, temporarily bans the host for a short time (this is a transient issue in the app I'm working with). The problem is that the SYN floods can occasionally reach rates which are too fast for fail2ban to keep up with; I'll see 20-40 log messages per second, and eventually fail2ban falls behind and becomes ineffective. To add insult to injury, it continues consuming a LOT of CPU as it tries to catch up. I have verified that DROP chained packets from hosts already banned by fail2ban are not logged, and thus do not add to its load. What are my options here? I have a few ideas, but no clear path forward. Could I make the log-parse regex "easier" so it takes fewer cycles? Would using iptables --log-prefix to put a token near the start of the log message, and/or otherwise simplifying/altering the fail2ban regex help? Here is the current fail2ban config line containing a regex: failregex = kernel:.*?SRC=(?:::f{4,6}:)?(?P<host>[\w\-.^_]+) DST.*?SYN Is there a faster way for fail2ban to watch for the packets exceeding the limits than parsing kern.log? Could fail2ban be run under PyPy instead of CPython with minimal nonstandard wizardry (the OS is Raspbian 7, so, mostly Debian 7)? Is there something better than fail2ban that I could use to watch for the packets which exceed the SYN limits, and after N exceeds in X seconds, temporarily put the offending IP into the iptables DROP bucket, and take it out when the ban timer expires? Again, I'd vastly prefer a solution that uses as much software available in Debian as possible, though I can build Debian packages in a pinch.

    Read the article

  • Overriding routes on Openvpn client, iproute, iptables2

    - by sarvavijJana
    I am looking for some way to route packets based on its destination ports switching regular internet connection and established openvpn tunnel. This is my configuration OpenVPN server ( I have no control over it ) OpenVPN client running ubuntu wlan0 192.168.1.111 - internet connected if Several routes applied on connection to openvpn from server: /sbin/route add -net 207.126.92.3 netmask 255.255.255.255 gw 192.168.1.1 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 5.5.0.1 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 5.5.0.1 And I need to route packets regarding it's destination ports for ex: 80,443 into vpn everything else directly to isp connection 192.168.1.1 What i have used during my attempts: iptables -A OUTPUT -t mangle -p tcp -m multiport ! --dports 80,443 -j MARK --set-xmark 0x1/0xffffffff ip rule add fwmark 0x1 table 100 ip route add default via 192.168.1.1 table 100 I was trying to apply this settings using up/down options of openvpn client configuration All my attempts reduced to successful packet delivery and response only via vpn tunnel. Packets routed bypassing vpn i have used some SNAT to gain proper src address iptables -A POSTROUTING -t nat -o $IF -p tcp -m multiport --dports 80,443 -j SNAT --to $IF_IP failed in SYN-ACK like 0 0,1 0,1: "70","192.168.1.111","X.X.X.X","TCP","34314 > 81 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=18664016 TSER=0 WS=7" "71","X.X.X.X","192.168.1.111","TCP","81 > 34314 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1428 TSV=531584430 TSER=18654692 WS=5" "72","X.X.X.X","192.168.1.111","TCP","81 > 34314 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1428 TSV=531584779 TSER=18654692 WS=5" "73","192.168.1.111","X.X.X.X","TCP","34343 > 81 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=18673732 TSER=0 WS=7" I hope someone has already overcome such a situation or probably knows better approach to fulfill requirements. Please kindly give me a good advice or working solution.

    Read the article

  • iptables blocking ssh communication

    - by Michal Sapsa
    I'm using this script for iptables: #!/bin/sh echo "1" > /proc/sys/net/ipv4/ip_forward iptables -F iptables -X iptables -F -t nat iptables -X -t nat iptables -F -t filter iptables -X -t filter iptables -t filter -P FORWARD DROP iptables -t filter -A FORWARD -s 192.168.0.0/255.255.0.0 -d 0/0 -j ACCEPT iptables -t filter -A FORWARD -s 0/0 -d 192.168.0.0/255.255.0.0 -j ACCEPT iptables -t nat -A POSTROUTING -s 10.8.0.1/255.255.255.0 -j MASQUERADE iptables -A FORWARD -s 10.8.0.1/255.255.255.0 -j ACCEPT iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu iptables -t nat -A PREROUTING -i eth1 -p udp --dport 16161 -j DNAT --to 192.168.0.251:16161 iptables -t nat -A PREROUTING -i eth1 -p udp --sport 16161 -j DNAT --to 192.168.0.251:16161 #openvpn iptables -I INPUT -p tcp --dport 1194 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT I end up with some iptables rules that should work but don't work - probably because of me. # Generated by iptables-save v1.4.12 on Mon May 26 13:15:43 2014 *raw :PREROUTING ACCEPT [1657523:1357257330] :OUTPUT ACCEPT [36804:34834370] -A PREROUTING -p icmp -j TRACE -A PREROUTING -p tcp -j TRACE -A OUTPUT -p icmp -j TRACE -A OUTPUT -p tcp -j TRACE COMMIT # Completed on Mon May 26 13:15:43 2014 # Generated by iptables-save v1.4.12 on Mon May 26 13:15:43 2014 *nat :PREROUTING ACCEPT [5033:345623] :INPUT ACCEPT [154:34662] :OUTPUT ACCEPT [6:1968] :POSTROUTING ACCEPT [2:120] -A PREROUTING -i eth0 -p tcp -m tcp --dport 16161 -j DNAT --to-destination 192.168.0.251:22 -A PREROUTING -i eth1 -p tcp -m tcp --dport 16161 -j DNAT --to-destination 192.168.0.251:22 -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE COMMIT # Completed on Mon May 26 13:15:44 2014 # Generated by iptables-save v1.4.12 on Mon May 26 13:15:44 2014 *filter :INPUT ACCEPT [548:69692] :FORWARD DROP [8:384] :OUTPUT ACCEPT [2120:1097479] -A INPUT -p udp -m udp --dport 1194 -j ACCEPT -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -s 192.168.0.0/16 -j ACCEPT -A FORWARD -d 192.168.0.0/16 -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -i eth1 -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT COMMIT TRACE at PREROUTEING AND OUTPUT are only for debuging this thing. When I ssh at public ip with port 16161 I don't get any message, only TimeOut so it looks like I don't get communication back to remote server. ETH0 is the world, ETH1 is LAN Any IPTABLES Masters willing to give a hand ? iptables -vL Chain INPUT (policy ACCEPT 20548 packets, 3198K bytes) pkts bytes target prot opt in out source destination 38822 7014K ACCEPT udp -- any any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:openvpn Chain FORWARD (policy DROP 1129 packets, 64390 bytes) pkts bytes target prot opt in out source destination 214K 11M TCPMSS tcp -- any any anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS clamp to PMTU 4565K 1090M ACCEPT all -- any any 192.168.0.0/16 anywhere 5916K 7315M ACCEPT all -- any any anywhere 192.168.0.0/16 0 0 ACCEPT all -- any any 10.8.0.0/24 anywhere 0 0 ACCEPT tcp -- any any anywhere 192.168.0.251 tcp dpt:16161 Chain OUTPUT (policy ACCEPT 59462 packets, 19M bytes) pkts bytes target prot opt in out source destination

    Read the article

  • Open ports for Apache Tomcat-7.0.32 on Linux Mandriva

    - by ivanov-void
    I installed Apache Tomcat-7.0.32 on Linux Mandriva and I want to make it accessible. for this I need to open ports in iptables. I added the following rules- iptables -A INPUT -p tcp -m tcp --dport 8081 --syn -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8010 --syn -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8444 --syn -j ACCEPT iptables -A INPUT -p tcp -m tcp --dport 8006 --syn -j ACCEPT then save and restart iptables - /etc/init.d/iptables save /etc/init.d/iptables restart verify, that ports is open - netstat -tulpn | less I am running command - netstat-ntpl | grep java and see - When I disable the firewall, I see the start page of the server on request - http://server_ip:8081/ When enable - server not accessible from outside. In what may be the cause? I would be most grateful for the information! Thank you!

    Read the article

  • Custumizing Syntax Highlighting in Vim

    - by sixtyfootersdude
    Hey I have defined a few custom file types for vim. I have done this like this: In vimrc: au BufWinEnter,BufRead,BufNewFile *.jak set filetype=jak And then in jak.vim syn match arrows /<-/ syn match arrows /->/ syn match arrows /=>/ syn match arrows /<=/ highlight arrows ctermfg=brown ... This works. (Formatting applies to any file opened with vim with file extension .jak) My question is how I can keep all the current formatting for a file type but add functionality. For example I would like to add this functionality for .vim files: syn keyword yellow yellow highlight yellow ctermfg=yellow ... (so that I can see how my terminal interpenetrates different colors before choosing them.) I have created ~/.vim/syntax/vim.vim (file only contains the above) and put this into my vimrc: au BufWinEnter,BufRead,BufNewFile *.vim set filetype=vim This has no effect. The word yellow is not colored yellow. I have also tried putting my vim.vim file into ~/.vim/after/syntax/vim.vim As suggested here This is the approach that I would like to take. Seems clean and easily maintainable.

    Read the article

  • Vim syntax highlighting: make region only match on one line

    - by sixtyfootersdude
    Hello I have defined a custom file type with these lines: syn region SubSubtitle start=+=+ end=+=+ highlight SubSubtitle ctermbg=black ctermfg=DarkGrey syn region Subtitle start=+==+ end=+==+ highlight Subtitle ctermbg=black ctermfg=DarkMagenta syn region Title start=+===+ end=+===+ highlight Title ctermbg=black ctermfg=yellow syn region MasterTitle start=+====+ end=+====+ highlight MasterTitle cterm=bold term=bold ctermbg=black ctermfg=LightBlue I enclose all of my headings in this kind of document like this: ==== Biggest Heading ==== // this will be bold and light blue ===Sub heading === // this will be yellow bla bla bla // this will be normally formatted However right now when ever I use an equals sign in my code it thinks that it is a title. Is there anyway that I can force a match to be only on one line?

    Read the article

  • Java CORBA Client Disconnects Immediately

    - by Benny
    I have built a Java CORBA application that subscribes to an event server. The application narrows and logs on just fine, but as soon as an event is sent to the client, it breaks with the error below. Please advise. 2010/04/25!13.00.00!E00555!enserver!EventServiceIF_i.cpp!655!PID(7390)!enserver - e._info=system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0' TAO exception, minor code = 54410093 (invocation connect failed; ECONNRESET), completed = NO EDIT: Please note, this only happens when running on some machines. It works on some, but not others. Even on the same platform (I've tried Windows XP/7 and CentOS linux) Some work, some don't... Here is the WireShark output...looks like the working PC is much more interactive with the network compared to the non-working PC. Working PC No. Time Source Destination Protocol Info 62 28.837255 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 63 28.907068 fe80::5de0:8d21:937e:c649 ff02::1:3 LLMNR Standard query A isatap 64 28.907166 10.10.10.209 224.0.0.252 LLMNR Standard query A isatap 65 29.107259 10.10.10.209 10.255.255.255 NBNS Name query NB ISATAP<00> 66 29.227000 10.10.10.250 10.10.10.209 TCP 23120 > 50169 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1260 WS=0 67 29.227032 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [ACK] Seq=1 Ack=1 Win=66560 Len=0 68 29.238063 10.10.10.209 10.10.10.250 GIOP GIOP 1.1 Request s=326 id=5 (two-way): op=logon 69 29.291765 10.10.10.250 10.10.10.209 GIOP GIOP 1.1 Reply s=420 id=5: No Exception 70 29.301395 10.10.10.209 10.10.10.250 GIOP GIOP 1.1 Request s=369 id=6 (two-way): op=registerEventStat 71 29.348275 10.10.10.250 10.10.10.209 GIOP GIOP 1.1 Reply s=60 id=6: No Exception 72 29.405250 10.10.10.209 10.10.10.250 TCP 50170 > telnet [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 73 29.446055 10.10.10.250 10.10.10.209 TCP telnet > 50170 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1260 WS=0 74 29.446128 10.10.10.209 10.10.10.250 TCP 50170 > telnet [ACK] Seq=1 Ack=1 Win=66560 Len=0 75 29.452021 10.10.10.209 10.10.10.250 TELNET Telnet Data ... 76 29.483537 10.10.10.250 10.10.10.209 TELNET Telnet Data ... 77 29.483651 10.10.10.209 10.10.10.250 TELNET Telnet Data ... 78 29.523463 10.10.10.250 10.10.10.209 TCP telnet > 50170 [ACK] Seq=4 Ack=5 Win=32768 Len=0 79 29.554954 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [ACK] Seq=720 Ack=505 Win=66048 Len=0 Non-working PC No. Time Source Destination Protocol Info 1 0.000000 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 2 2.999847 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 3 4.540773 Cisco_3c:78:00 Cisco-Li_55:87:72 ARP Who has 10.0.0.1? Tell 10.10.10.209 4 4.540843 Cisco-Li_55:87:72 Cisco_3c:78:00 ARP 10.0.0.1 is at 00:1a:70:55:87:72 5 8.992284 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260

    Read the article

  • ufw portforwarding to virtualbox guest

    - by user85116
    My goal is to be able to connect using remote desktop on my desktop machine, to windows xp running in virtualbox on my linux server. My setup: server = debian squeeze, 64 bit, with a public IP address (host) virtualbox-ose 3.2.10 (from debian repo) windows xp running inside VBox as a guest; bridged networking mode in VBox, ip = 192.168.1.100 ufw as the firewall on debian, 3 ports are opened: 22 / ssh, 80 / apache, and 3389 for remote desktop My problem: If I try to use remote desktop on my home computer, I am unable to connect to the windows guest. If I first "ssh -X -C" into the debian server, then run "rdesktop 192.168.1.100", I am able to connect without issue. The windows firewall was configured to allow remote desktop connections, and I've even turned it off (as it is redundant here) to see if that was the problem but it made no difference. Since I am able to connect from inside the local subnet, I suspect that I have not setup my debian firewall correctly to handle connections from outside the LAN. Here is what I've done... First my ufw status: ufw status Status: active To Action From -- ------ ---- 22 ALLOW Anywhere 80 ALLOW Anywhere 3389 ALLOW Anywhere I edited /etc/ufw/sysctl.conf and added: net/ipv4/ip_forward=1 Edited /etc/default/ufw and added: DEFAULT_FORWARD_POLICY="ACCEPT" Edited /etc/ufw/before.rules and added: # setup port forwarding to forward rdp to windows VM *nat :PREROUTING - [0:0] -A PREROUTING -i eth0 -p tcp --dport 3389 -j DNAT --to-destination 192.168.1.100 -A PREROUTING -i eth0 -p udp --dport 3389 -j DNAT --to-destination 192.168.1.100 COMMIT # Don't delete these required lines, otherwise there will be errors *filter <snip> Restarted the firewall etc., but no connection. My log files on the debian host show this (my public ip address was removed for this posting but it is correct in the actual log): Feb 6 11:11:21 localhost kernel: [171991.856941] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 6 11:11:21 localhost kernel: [171991.856963] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27518 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 6 11:11:24 localhost kernel: [171994.856701] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 6 11:11:24 localhost kernel: [171994.856723] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27519 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 6 11:11:30 localhost kernel: [172000.856656] [UFW AUDIT] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Feb 6 11:11:30 localhost kernel: [172000.856678] [UFW ALLOW] IN=eth0 OUT=eth0 SRC=aaa.bbb.ccc.dd DST=192.168.1.100 LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=27520 DF PROTO=TCP SPT=54201 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 Although this is the current setup / configuration, I've also tried several variations of this; I thought maybe the ISP would be blocking 3389 for some reason and tried using different ports, but again there was no connection. Any ideas...? Did I forget to modify some file somewhere?

    Read the article

  • VIM does not detect syntax of .ssh/config

    - by Erik
    On a plain Ubuntu installation (12.04 in my case) when I have no ~/.vimrc VIM does not detect syntax of .ssh/config. Syntax highlighting works, but it does not set the correct filetype. vi ~/.ssh/config :set syn? >syntax=conf When I do: set syn=sshconfig Then the syntax highlighting is as it should be. Why isn't the filetype automatically identified? And how can it be set automatically?

    Read the article

  • No Telnet login prompt when used over SSH tunnel

    - by SCO
    Hi there ! I have a device, let's call it d1, runnning a lightweight Linux. This device is NATed by my internet box/router, hence not reachable from the Internet. That device runs a telnet daemon on it, and only has root as user (no pwd). Its ip address is 192.168.0.126 on the private network. From the private network (let's say 192.168.0.x), I can do: telnet 192.168.0.126 Where 192.168.0.126 is the IP address in the private network. This works correctly. However, to allow administration, I'd need to access that device from outside of that private network. Hence, I created an SSH tunnel like this on d1 : ssh -R 4455:localhost:23 ussh@s1 s1 is a server somewhere in the private network (but this is for testing purposes only, it will endup somewhere in the Internet), running a standard Linux distro and on which I created a user called 'ussh'. s1 IP address is 192.168.0.48. When I 'telnet' with the following, let's say from c1, 192.168.0.19 : telnet -l root s1 4455 I get : Trying 192.168.0.48... Connected to 192.168.0.48. Escape character is '^]'. Connection closed by foreign host . The connection is closed after roughly 30 seconds, and I didn't log. I tried without the -l switch, without any success. I tried to 'telnet' with IP addresses instead of names to avoid reverse DNS issues (although I added to d1 /etc/hosts a line refering to s1 IP/name, just in case), no success. I tried on another port than 4455, no success. I gathered Wireshark logs from s1. I can see : s1 sends SSH data to c1, c1 ACK s1 performs an AAAA DNS request for c1, gets only the Authoritave nameservers. s1 performs an A DNS request, then gets c1's IP address s1 sends a SYN packet to c1, c1 replies with a RST/ACK s1 sends a SYN to c1, C1 RST/ACK (?) After 0.8 seconds, c1 sends a SYN to s1, s1 SYN/ACK and then c1 ACK s1 sends SSH content to d1, d1 sends an ACK back to s1 s1 retries AAAA and A DNS requests After 5 seconds, s1 retries a SYN to c1, once again it is RST/ACKed by c1. This is repeated 3 more times. The last five packets : d1 sends SSH content to s1, s1 sends ACK and FIN/ACK to c1, c1 replies with FIN/ACK, s1 sends ACK to c1. The connection seems to be closed by the telnet daemon after 22 seconds. AFAIK, there is no way to decode the SSH stream, so I'm really stuck here ... Any ideas ? Thank you !

    Read the article

  • What does this rule mean

    - by Kenyana
    When I run $ sudo iptables -L This is what I get Chain INPUT (policy ACCEPT) target prot opt source destination REJECT tcp -- anywhere anywhere tcp dpt:www flags:FIN,SYN,RST,ACK/SYN #conn/32 > 20 reject-with tcp-reset Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination What does this mean? I am pretty new to the whole Ubuntu world. I cannot access webmin at times, keep getting The connection has timed out error.

    Read the article

  • pfSense router on a LAN with two gateways

    - by JohnCC
    I have a LAN with an ADSL modem/router on it. We have just gained an alternative high-speed internet connection at our location, and I want to connect the LAN to it, eventually dropping the ADSL. I've chosen to use a small PFSense box to connect the LAN to the new WAN connection. Two servers on the LAN run services accessible to the outside via NAT using the single ADSL WAN IP. We have DNS records which point to this IP. I want to do the same via the new connection, using the WAN IP there. That connection permits multiple IPs, so I have configured pfSense using virtual IP's, 1:1 NAT and appropriate firewall rules. When I change the servers' default gateway settings to the pfSense box, I can access the services via the new WAN IPs without a problem. However, I can no longer access them via the old WAN IP. If I set the servers' default gateway back to the ADSL router, then the opposite is true - I can access the services via the ADSL IP, but not via the new one. In the first case, I believe this is because an incoming SYN packet arrives at the ADSL WAN IP, and is NAT'd and sent to the internal IP of the server. The server responds with a SYN/ACK which it sends via its default gateway, the pfSense box. The pfSense box sees a SYN/ACK that it saw no SYN for and drops the packet. Is there any sensible way around this? I would like the services to be accessible via both IPs for a short period at least, since once I change the DNS it will take a while before everyone picks up the new address.

    Read the article

  • Nginx proxy to IIS Connection Timeout

    - by MitMaro
    I am having an issue with random timeouts with a Nginx proxy connecting to an IIS machine. I have been watching a packet capture between the two servers and it seems that the IIS machine is receiving a SYN packet but is not responding with what I think should be an ACK response. Before the timeout occurs there seems to be a slower response from the IIS server. There is no unusual memory or processor usage on the IIS or Nginx machine. Some information on the servers and setup: Nginx Machine: Ubuntu 10.04 64bit Nginx 0.7.65 Amazon EC2 Windows Machine: Windows Server 2008 IIS 7 ASP.net Application in Integrated Mode Nginx Error: 2011/01/10 17:57:40 [error] 8297#0: *30 connect() failed (110: Connection timed out) while connecting to upstream, client: 209.***.***.***, server: secure.example.com, request: "GET /a/path/deliver.aspx HTTP/1.1", upstream: "http://***.***.***.****:****//another/path/deliver.aspx", host: "secure.example.com" WireShark Packets 6521.449528 10.***.***.*** -> 174.***.***.*** TCP 38695 > us-cli [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=477422103 TSER=0 WS=7 6524.443239 10.***.***.*** -> 174.***.***.*** TCP 38695 > us-cli [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=477422403 TSER=0 WS=7 6530.443241 10.***.***.*** -> 174.***.***.*** TCP 38695 > us-cli [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=477423003 TSER=0 WS=7

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8  | Next Page >