6in4 tunnel with wrong source addres

RouterOS General
1

Hi,

I have a 6in 4 tunnel with the following config:

/interface 6to4
add !keepalive local-address=192.168.32.1 name=Home remote-address=192.168.0.1

My problem with this is that when trying to send something through the tunnel, the source address is not the specified address, but the WAN addres:

77 9753... home.crill... 192.168.0.1                                 10.160.22.11                                ipv6-encap   1300   1 no 
78 9753... home.crill... 192.168.0.1                                 10.160.22.11                                ipv6-encap    902   1 no

I’m not sure what the issue could be here, I have checked my NAT rules, and removed any src-nat, except the default NAT:

add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

The 6in4 tunnel is not leaving the router through the WAN, but through an OpenVPN tunnel, and I have verified that the packets are arriving at the remote end, so they should not be subject to the default masquerade.

Any inputs would be very appreciated! :slight_smile:

Thanks!

Simple HE 6to4 tunnel can Tx but not Rx
2

Are you using mangle rules and routes with a routing-mark to route the packets via the OpenVPN?

3

I’m not using mangle, at least not that I am aware of. There is nothing under /ip firewall mangle. The frames are routed through dynamic routes pushed from the remote Open VPN server.

4

Are you using ROS 7? I am not aware of the OpenVPN implementation in ROS 6 to accept routes pushed from the server.

Once you say you have removed some NAT rules, what does ip firewall connection print detail where protocol=ipv6-encap show?

5

I am using ROS 6.84, and Open VPN push routes are accepted from the server.

The output of ip firewall connection print detail is:

19  S C  s  protocol=ipv6-encap src-address=192.168.32.1 
            dst-address=192.168.0.1 reply-src-address=192.168.0.1 
            reply-dst-address=10.160.22.11 timeout=9m59s orig-packets=29 858 
            orig-bytes=4 618 600 orig-fasttrack-packets=0 
            orig-fasttrack-bytes=0 repl-packets=37 352 repl-bytes=41 846 646 
            repl-fasttrack-packets=0 repl-fasttrack-bytes=0 orig-rate=1984bps 
            repl-rate=1984bps

So there is obviously something going on with the reply-dst-address, but I am not sure where it may be coming from.

6

Mmm, a custom release :grin: (I know it is a typo).

As you’ve properly found in the ip firewall connection print detail output, the packets are sent from the correct IP address (src-address=192.168.32.1), but the connection has been src-nated (reply-dst-address=10.160.22.11).

The thing is that the /ip firewall nat rules only handle the initial packet of each connection, and the decision taken is inherited by all subsequent packets of the same connection. So after you have disabled or removed the action=src-nat (or action=masquerade) rule responsible for this, you still have to remove the connection from the connection tracking table:
/ip firewall connection remove [find protocol=ipv6-encap]
Or disable the tunnel interface for 10 minutes until the connection disappears from the list on timeout expiration and then re-enable it.
The first packet to come when the connection doesn’t exist in the connection tracking table is treated by the NAT chains and creates a new connection.

7

Thanks a million! I had tried to disable the tunnel, but not for 10 minutes. Removing the connection did the trick! :slight_smile: