Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 2266 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[BUG] 9.107-33 Firewall Rules and IPSEC not working at tun1

christian1980nrw
In our case we are forwarding an external static ip of an openvpn-server to the utm by a site-to-site ssl-vpn-tunnel. The reason is that we still need a public and reachable ip in case of umts-backup. If you connect by umts, most of the provider are blocking the incoming ipv4 traffic or you will be behind a nat. Incoming connections will not be possible. We still have to receive emails and to connect the red devices 24/7.

Iptables-Rules of the openvpn-server:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source IPOFOVPNSERVER
iptables -t nat -I PREROUTING -d IPOFOVPNSERVER -j DNAT --to-destination 10.8.0.2

The utm will connect as client and get the ip 10.8.0.2 by the openvpn server and the traffic will be natted through the tunnel. The new default gateway of the utm will be the 10.8.0.1 by "push redirect-gateway" in the openvpn config.
Almost everything is working. The dyndns accounts are updating, the sophos red is connecting,  the webproxy is working and emails can be received by the ip of the openvpn server. Even if you are connected by umts and your provider is blocking most of the services.

Our problem is, that the firewall rules are not working with tun1 ip 10.8.0.2. By default, a incoming ipsec-connection at port 500 will be blocked and its not possible to create working rules. If you create rules, the packets will still be dropped by default.[:O]

Another nice-to-have feature would be "activating a site-to-site ssl-vpn-tunnel in case of umts-backup". At this time we have to activate it manually, because this is only possible for ipsec-tunnel in the uplink-monitoring.


Here is a quick drawing of the described topology:


Thanks for checking the bug.
Christian


This thread was automatically locked due to age.
Parents
  • 0
    Hi, 

    1. did you have this working in an earlier UTM version?

    2. can you post the drop entries from the full firewall log?

    3. if 'no' on #1, also read https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/22065

    Barry
  • 0 in reply to BarryG
    Thanks for your reply.

    1. did you have this working in an earlier UTM version?

    Yes, it was working in the 8.311 too, but we didnt work with the firewall rules.
    I have got a spare-appliance still with 8.311 here too. If its helpful ill connect it tomorrow and check if the rules and incoming ipsec traffic on tun1 will be dropped too.


    2. can you post the drop entries from the full firewall log?

    This are two examples of dropped packets. If more is needed, please tell me which log is helpful too.
    The first is out of the local lan, going to port 81 of a host to access a web based ticket system. The second is a incoming ipsec connection of the same host on port 500 udp. Even if you create test rules and allow any host any service to 90.79.83.2 on any interface and the second rule 90.79.83.2 with any service on any interface to any, port 81 and 500 of this exaples will still be dropped.

    ulogd[4591]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth0" outitf="tun1" srcmac="0:1e:e7:18:1a:4c" dstmac="6:1a:12:12:1d:48" srcip="192.168.178.38" dstip="90.79.83.2" proto="6" length="60" tos="0x00" prec="0x00" ttl="63" srcport="47869" dstport="81" tcpflags="SYN"

    ulogd[4591]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="tun1" srcip="90.79.83.2" dstip="10.8.0.2" proto="17" length="608" tos="0x00" prec="0x00" ttl="246" srcport="500" dstport="500"
     

    I also noticed that tun1 will not be listed in the advanced network definitions, even if its connected:


    Thanks again.
    Christian
Reply
  • 0 in reply to BarryG
    Thanks for your reply.

    1. did you have this working in an earlier UTM version?

    Yes, it was working in the 8.311 too, but we didnt work with the firewall rules.
    I have got a spare-appliance still with 8.311 here too. If its helpful ill connect it tomorrow and check if the rules and incoming ipsec traffic on tun1 will be dropped too.


    2. can you post the drop entries from the full firewall log?

    This are two examples of dropped packets. If more is needed, please tell me which log is helpful too.
    The first is out of the local lan, going to port 81 of a host to access a web based ticket system. The second is a incoming ipsec connection of the same host on port 500 udp. Even if you create test rules and allow any host any service to 90.79.83.2 on any interface and the second rule 90.79.83.2 with any service on any interface to any, port 81 and 500 of this exaples will still be dropped.

    ulogd[4591]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth0" outitf="tun1" srcmac="0:1e:e7:18:1a:4c" dstmac="6:1a:12:12:1d:48" srcip="192.168.178.38" dstip="90.79.83.2" proto="6" length="60" tos="0x00" prec="0x00" ttl="63" srcport="47869" dstport="81" tcpflags="SYN"

    ulogd[4591]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="tun1" srcip="90.79.83.2" dstip="10.8.0.2" proto="17" length="608" tos="0x00" prec="0x00" ttl="246" srcport="500" dstport="500"
     

    I also noticed that tun1 will not be listed in the advanced network definitions, even if its connected:


    Thanks again.
    Christian
Children
No Data