Results 1 to 7 of 7

Thread: SuSEFirewall2, iptables and redsocks (socks redirector)

  1. #1

    Default SuSEFirewall2, iptables and redsocks (socks redirector)

    Hello,

    i'm trying to setup a OpenSuSE 13.1 to forward all traffic for a certain network through the redsocks redirector (http://darkk.net.ru/redsocks/).

    Here is what I did so far:

    In the file /etc/sysconfig/SuSEfirewall2 I configured, that custom rules should be parsed:
    Code:
    FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"
    In /etc/sysconfig/scripts/SuSEfirewall2-custom I added the following to the section fw_custom_after_chain_creation
    Code:
        # Create new chain
        iptables -t nat -N REDSOCKS
    
        # Ignore addresses not intended for redsocks
        iptables -t nat -A REDSOCKS ! -d XXX.0.0.0/8 -j RETURN
    
        # Anything else should be redirected to redsocks listening at 30002
        iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 30002
    
        #connect output to redsocks chain
        iptables -t nat -A OUTPUT -p tcp -j REDSOCKS
    When I restart SuSEFirewall2, iptables is configured accordingly. I checked that with 'iptables -t nat -L'.
    But the rules are not honored. No packages for the target network are redirected to the redsocks redirector listening on port 30002.

    When I stop the SuSEFirewall2 and enter the iptable rules manually, everything works fine.

    Question: What setting to the SuSEFirewall2 are needed, so that IP packages targeting XXX.0.0.0/8 addresses are send through the redsocks redirector.

    Regards,
    Ralf

  2. #2
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,264
    Blog Entries
    2

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    Although it might not make a difference,
    Have you tried entering your custom rules using the YAST Firewall applet?

    Although I wouldn't know if it applies here, various times in the past people have reported that manual configurations don't always "take" but work if entered using YAST.

    I'm also a bit curious about why you might want to use redsocks...
    The more commonly used dnsmasq does much (but maybe not all) of what redsocks does.
    I haven't looked closely, but maybe even ordinary masquerading in the SUSE FW might accomplish what you want... Strictly speaking, it's not redirecting to a SOCKS proxy, but it does enable re-routing, possibly to a firewall or proxy.

    TSU

  3. #3

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    TSU, thanks for your response.

    I looked at the FW applet, but I just don't understand how to enter this type of rules with it.

    Perhaps I should try to explain the general setup.

    I'm connected to a network A and need to access servers on a network B. The only passage between this two networks is a Socks5 server. So all requests to network B need to go to that Socks server.

    Redsocks is locally installed and listens to port 30002 (a number I have chosen) and handles theSocks connection to that Socks server. With redsocks and iptables it is possible to configure that all request for network B are redirected to the local port 30002 and are handled by redsocks. I was able to configure the needed rules in iptables, but at the price of disabling the SuSEFirewall.

    I would prefer a solution with the firewall running. As explained above, it is possible to configure the needed rules with the firewall, but somehow that doesn't work. I guess some other rule of the firewall prevents it from functioning, but I don't understand which one. I switched logging to "Log All" for accepted and not accepted packages, but that didn't log anything related.

    Working without the firewall might be an acceptable solution, as OpenSuSE runs on a VM with NATed network interface. But I now want to know how to make it work with SuSEFirewall.

    Ralf

  4. #4

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    Ok, I learned how to trace iptable rules.

    From the below trace it looks as if the IP packets end in a loop in the iptables rules. After some loops it seems as if the IP packet disappears. It didn't reach the redsocks Socks5 redirector nor did I find anythings in the logs.

    Now I'm lost. Any ideas?

    Regards
    Ralf

    Code:
    2014-12-07T19:43:11.805851+01:00 linux-vm kernel: [20865.962502] TRACE: nat:REDSOCKS:rule:2 IN= OUT=enp0s3 SRC=10.0.2.15 DST=XX.3.20.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=443 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) UID=1000 GID=1000 
    2014-12-07T19:43:11.805940+01:00 linux-vm kernel: [20865.962535] TRACE: nat:REDSOCKS:rule:3 IN= OUT=enp0s3 SRC=10.0.2.15 DST=XX.3.20.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=443 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) UID=1000 GID=1000 
    
    2014-12-07T19:43:11.805965+01:00 linux-vm kernel: [20865.962573] TRACE: filter:OUTPUT:policy:2 IN= OUT=enp0s3 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) UID=1000 GID=1000 
    2014-12-07T19:43:11.805997+01:00 linux-vm kernel: [20865.962604] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=lo SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) UID=1000 GID=1000 
    2014-12-07T19:43:11.806017+01:00 linux-vm kernel: [20865.962621] TRACE: nat:POSTROUTING:policy:1 IN= OUT=lo SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) UID=1000 GID=1000 
    
    2014-12-07T19:43:11.806047+01:00 linux-vm kernel: [20865.962681] TRACE: raw:PREROUTING:rule:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:11.806070+01:00 linux-vm kernel: [20865.962696] TRACE: raw:PREROUTING:rule:2 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:11.806099+01:00 linux-vm kernel: [20865.962726] TRACE: raw:PREROUTING:policy:3 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:11.806119+01:00 linux-vm kernel: [20865.962744] TRACE: mangle:PREROUTING:policy:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:11.806457+01:00 linux-vm kernel: [20865.962761] TRACE: mangle:INPUT:policy:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:11.806496+01:00 linux-vm kernel: [20865.962796] TRACE: filter:INPUT:rule:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49706 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139CFCB0000000001030307) 
    2014-12-07T19:43:12.808835+01:00 linux-vm kernel: [20866.965880] TRACE: filter:OUTPUT:policy:2 IN= OUT=enp0s3 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49707 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139D3B60000000001030307) UID=1000 GID=1000 
    2014-12-07T19:43:12.808850+01:00 linux-vm kernel: [20866.965969] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=lo SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49707 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A0139D3B60000000001030307) UID=1000 GID=1000 
    
    // previous block repeats another 5 times
    
    2014-12-07T19:44:14.963906+01:00 linux-vm kernel: [20929.120405] TRACE: raw:PREROUTING:rule:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307) 
    2014-12-07T19:44:14.963926+01:00 linux-vm kernel: [20929.120452] TRACE: raw:PREROUTING:rule:2 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307) 
    2014-12-07T19:44:14.963943+01:00 linux-vm kernel: [20929.120480] TRACE: raw:PREROUTING:policy:3 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307) 
    2014-12-07T19:44:14.963991+01:00 linux-vm kernel: [20929.120527] TRACE: mangle:PREROUTING:policy:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307) 
    2014-12-07T19:44:14.964010+01:00 linux-vm kernel: [20929.120579] TRACE: mangle:INPUT:policy:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307) 
    2014-12-07T19:44:14.964028+01:00 linux-vm kernel: [20929.120605] TRACE: filter:INPUT:rule:1 IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=10.0.2.15 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=49712 DF PROTO=TCP SPT=56027 DPT=30013 SEQ=1554320865 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A013AC6800000000001030307)

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,264
    Blog Entries
    2

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    Quote Originally Posted by rakusch View Post
    TSU, thanks for your response.

    I looked at the FW applet, but I just don't understand how to enter this type of rules with it.

    Perhaps I should try to explain the general setup.

    I'm connected to a network A and need to access servers on a network B. The only passage between this two networks is a Socks5 server. So all requests to network B need to go to that Socks server.

    Redsocks is locally installed and listens to port 30002 (a number I have chosen) and handles theSocks connection to that Socks server. With redsocks and iptables it is possible to configure that all request for network B are redirected to the local port 30002 and are handled by redsocks. I was able to configure the needed rules in iptables, but at the price of disabling the SuSEFirewall.

    I would prefer a solution with the firewall running. As explained above, it is possible to configure the needed rules with the firewall, but somehow that doesn't work. I guess some other rule of the firewall prevents it from functioning, but I don't understand which one. I switched logging to "Log All" for accepted and not accepted packages, but that didn't log anything related.

    Working without the firewall might be an acceptable solution, as OpenSuSE runs on a VM with NATed network interface. But I now want to know how to make it work with SuSEFirewall.

    Ralf
    Have you tried entering your custom rules in the Custom Rules tab of the YAST FW applet?

    TSU

  6. #6

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    Quote Originally Posted by tsu2 View Post
    Have you tried entering your custom rules in the Custom Rules tab of the YAST FW applet?

    TSU
    TSU, if I click the "Add" button on the Custom Rules tab, I have the input fields

    • Source Network
    • Protocol drop-down
    • Destination Port
    • Source Port
    • Additional Options


    Lets assume I simplify my iptables rule to:
    Code:
    iptables -t nat -A OUTPUT -p tcp -d XXX.0.0.0/8 -j REDIRECT --to-ports 30013
    How would I enter this into that dialog?

    Ralf

  7. #7
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,264
    Blog Entries
    2

    Default Re: SuSEFirewall2, iptables and redsocks (socks redirector)

    Quote Originally Posted by rakusch View Post
    TSU, if I click the "Add" button on the Custom Rules tab, I have the input fields

    • Source Network
    • Protocol drop-down
    • Destination Port
    • Source Port
    • Additional Options


    Lets assume I simplify my iptables rule to:
    Code:
    iptables -t nat -A OUTPUT -p tcp -d XXX.0.0.0/8 -j REDIRECT --to-ports 30013
    How would I enter this into that dialog?

    Ralf
    Not sure why you're implementing NAT, but if you want to continue to do so, set up a masquerading network. Masquerading might require setting up a new "dummy/localhost" interface if you're not actually binding to a real interface.

    Then,
    I would try


    • Source Network XXX.0.0.0
    • Protocol drop-down
    • Destination Port 30013
    • Source Port
    • Additional Options


    Another try if you can define everything in one command as you appear to do so, is to specify the source network and then put everything else in the "Additional Options" field.

    Lastly, keep in mind that the SUSE FW is a choice, a fairly useful tool that works for a majority of scenarios but doesn't cover <every> scenario.
    Other IPtables management can also be used in place of,
    or as you've already established may be better managed simply from the command line only.

    TSU

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •