MikroTik

Community discussions
https://forum.mikrotik.com/

Ipsec site to site nat dilemma

https://forum.mikrotik.com/viewtopic.php?t=131099

Page 1 of 1

Ipsec site to site nat dilemma

Posted: Tue Feb 20, 2018 9:41 pm
by marwooj
I I have working site to site ipsec vpn. Just going trought configuration and compeering it to documentation:
https://wiki.mikrotik.com/wiki/Manual:I ... Sec_Tunnel
I found there should be nat on bouth routers that I do not have in mines.

I do have:
Code: Select all
/ip firewall raw
add action=notrack chain=prerouting src-address=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting src-address=10.1.202.0/24 dst-address=10.1.101.0/24
but I do not have:
Code: Select all
Office1 router:

/ip firewall nat
add chain=srcnat action=accept  place-before=0 \
 src-address=10.1.202.0/24 dst-address=10.1.101.0/24

Office2 router:

/ip firewall nat
add chain=srcnat action=accept  place-before=0 \
 src-address=10.1.101.0/24 dst-address=10.1.202.0/24

So how is mine tunnel working?

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 12:39 am
by Sob
Because in the end, both variants have the same effect - packets won't get to main srcnat rule. With accept rules it's because they are first and action=access stops further processing in srcnat chain. Yours stop tracking completely, and because NAT needs tracking, untracked packets won't by touched by it.

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 2:20 pm
by marwooj
Great, just one more question, when I am on my remote network let say with Remote Desktop on some host inside that network an I pretend It is my local site, I am not able to ssh to router that is on opposed site. Everything else is working, all other remote IP are accessible. And I can ping router remote/LAN IP too.

Where should I put and what rule to be able to ssh into remote router not just ping?

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 4:30 pm
by sindy
Great, just one more question, when I am on my remote network let say with Remote Desktop on some host inside that network an I pretend It is my local site, I am not able to ssh to router that is on opposed site. Everything else is working, all other remote IP are accessible. And I can ping router remote/LAN IP too.

Where should I put and what rule to be able to ssh into remote router not just ping?
To me it is too many relative references - opposite, remote, local.

Please use absolute names - your PC (1) at site A connects to another PC (2) on site B using RDP. Then, you try to connect from the remote-controlled PC (2) to an ssh server which is located where? On site A, site B or yet another site?

Did you try to connect from PC (2) to the same ssh server while physically present at that PC? In another words, is that problem related to the firewall between PC (2) and the server, or is the use of RDP somehow involved because the success of the ssh connection depends on which way you access PC (2)?

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 5:41 pm
by marwooj
PC A on site LAN A is trying to connect with ssh to router B on site LAN B, all hosts from LAN B are accessible from PC A, except router B. PC A can ping router B, but not ssh. PC A can go to http 80 on PC B that is on site LAN B.

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 6:02 pm
by Sob
Probably firewall rules. Remember that incoming packets from tunnel look to router as if they were coming from internet. So if you limit ssh access to router from outside, connections from tunnel are affected as well. Check the "ipsec-policy" option, it can help you to tell tunneled and internet traffic apart.

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 7:07 pm
by marwooj
No luck whit this:
Code: Select all
1  chain=input action=accept protocol=tcp src-address=10.1.101.0/24 dst-port=22 log=no log-prefix="" ipsec-policy=in,ipsec 
2  chain=output action=accept protocol=tcp dst-address=10.1.101.0/24 src-port=22 log=no log-prefix="" ipsec-policy=out,ipsec

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 8:04 pm
by sindy
No luck whit this:
Code: Select all
1  chain=input action=accept protocol=tcp src-address=10.1.101.0/24 dst-port=22 log=no log-prefix="" ipsec-policy=in,ipsec 
2  chain=output action=accept protocol=tcp dst-address=10.1.101.0/24 src-port=22 log=no log-prefix="" ipsec-policy=out,ipsec
The context is important. If rule "1" above is the first one in the "/ip firewall filter" for "chain=input", and the "action=accept connection=state=establisted(,related)" one follows it somewhere later in that chain, before any "drop" rule with even less selective match condition in the same chain, it should work and the reason is somewhere else (maybe one of your raw or mangle rules). Or the SSH access to the router may be restricted to several IP addresses or subnets at "/ip service ssh" level.

The rule 2 above is usually not necessary, if we talk about "/ip firewall filter" context.

If that does not help find the issue, the output of "/export hide-sensitive" with eventual systematic replacement of all occurrences of each public address by some symbolic name, will be necessary to let us assist you further.

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 8:53 pm
by marwooj
I will provide "hide-sensitive".

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 9:40 pm
by marwooj
Code: Select all
# RouterOS 6.41.2

/interface bridge
add admin-mac=MAC arp=proxy-arp auto-mac=no name=bridge1
/interface ethernet
set [ find default-name=ether1 ] comment=WAN
set [ find default-name=ether2 ] arp=proxy-arp name=ether2-master
set [ find default-name=ether3 ] arp=proxy-arp
set [ find default-name=ether4 ] arp=proxy-arp
set [ find default-name=ether5 ] arp=proxy-arp
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add exclude=dynamic name=discover
add name=mactel
add name=mac-winbox
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=\
    aes-256-cbc,aes-128-cbc lifetime=7h30m pfs-group=modp2048
/ip pool
add name=dhcp ranges=10.8.8.100-10.8.8.254
add name=ipsec-RW ranges=10.9.9.2-10.9.9.254
add name=cm-ovpn-pool ranges=10.16.33.2-10.16.33.38
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge1 name=defconf
/ppp profile
add change-tcp-mss=yes comment=firstovpn dns-server=10.8.8.5,8.8.8.8 \
    local-address=10.8.8.1 name=oprofile remote-address=dhcp \
    use-encryption=required wins-server=10.8.8.5
add comment=OVPN dns-server=10.8.8.5,8.8.8.8 local-address=10.16.33.1 name=\
    OVPN_profile remote-address=cm-ovpn-pool use-encryption=required
/queue simple
add max-limit=50M/50M name=NonVoIPTrafficQueue packet-marks=NonVoipPacketMark \
    queue=default/default target=ether1,ether1
/queue tree
add name=ether1_voip packet-mark=VoIPforTree parent=global priority=2 queue=\
    default
add disabled=yes name=bridge1 packet-mark=VoIPforTree parent=global priority=\
    2 queue=default
add name=RDP packet-mark=toRDPserver parent=global priority=5 queue=default
add name=SSTP packet-mark=sstppm parent=global priority=3 queue=default
/snmp community
set [ find default=yes ] addresses=0.0.0.0/0
/interface bridge port
add bridge=bridge1 interface=ether2-master
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip neighbor discovery-settings
set discover-interface-list=discover
/interface list member
add comment=defconf interface=ether2-master list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=ether2-master list=discover
add interface=ether3 list=discover
add interface=ether4 list=discover
add interface=ether5 list=discover
add interface=bridge1 list=discover
add interface=ether2-master list=mactel
add interface=ether2-master list=mac-winbox
/interface ovpn-server server
set certificate=cm-ovpn-server.crt_0 cipher=blowfish128,aes128,aes192,aes256 \
    default-profile=OVPN_profile enabled=yes keepalive-timeout=disabled \
    require-client-certificate=yes
/interface sstp-server server
set certificate=ca.crt_0 default-profile=oprofile enabled=yes
/ip address
add address=10.8.8.1/24 comment=defconf interface=ether2-master network=\
    10.8.8.0
add address=WANIP250/30 interface=ether1 network=WANIP248
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid interface=ether1
/ip dhcp-relay
add dhcp-server=10.8.8.5,10.13.13.2 disabled=no interface=bridge1 name=\
    relay1
/ip dhcp-server network
add address=10.8.8.0/24 comment=defconf dns-server=\
    10.8.8.5,10.13.13.2,8.8.8.8,8.8.4.4 domain=cm.local gateway=10.8.8.1 \
    netmask=24 ntp-server=10.8.8.5,10.13.13.2 wins-server=\
    10.8.8.5,10.13.13.2
/ip dns
set allow-remote-requests=yes servers=10.8.8.5,10.13.13.2,8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall address-list
add address=10.8.8.20 comment=VoiIPlistLocal list=VoiIPlist
add address=VOIPPROXY comment=VoiIPlist_ list=VoiIPlist
add address=10.8.8.5 list=RDPlist
add address=10.13.13.2 list=RDPlist
/ip firewall filter
add action=accept chain=input disabled=yes dst-port=22 ipsec-policy=in,ipsec \
    protocol=tcp src-address=10.13.13.0/24
add action=accept chain=output disabled=yes dst-address=10.13.13.0/24 \
    ipsec-policy=out,ipsec protocol=tcp src-port=22
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
add action=accept chain=input protocol=icmp
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input dst-port=443 in-interface=ether1 protocol=tcp
add action=accept chain=input comment=OpenVPN dst-port=1194 in-interface=\
    ether1 protocol=tcp
add action=accept chain=input dst-port=4500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input connection-state=established
add action=accept chain=input connection-state=related
add action=drop chain=input in-interface=ether1
/ip firewall mangle
add action=change-mss chain=forward log-prefix=MSS new-mss=1300 \
    out-interface=ether1 passthrough=yes protocol=tcp src-mac-address=\
    !MAC tcp-flags=syn tcp-mss=1301-65535
add action=mark-packet chain=prerouting comment="PM: VoIPforTree" \
    dst-address-list=VoiIPlist new-packet-mark=VoIPforTree passthrough=yes
add action=mark-connection chain=prerouting comment=\
    "CM: from 10.8.8.20 VoIPConnectionMark" new-connection-mark=\
    VoIPConnectionMark passthrough=yes protocol=udp src-address-list=\
    VoiIPlist
add action=mark-connection chain=prerouting dst-address-list=VoiIPlist \
    new-connection-mark=VoIPConnectionMark passthrough=yes protocol=udp
add action=mark-packet chain=prerouting comment=\
    "PM: NonVoipPacketMark when !VoIPConnectionMark" connection-mark=\
    !VoIPConnectionMark new-packet-mark=NonVoipPacketMark packet-mark=\
    !VoIPforTree passthrough=yes
add action=log chain=prerouting comment=to_Log5060 disabled=yes dst-port=\
    5060 log=yes log-prefix=to_5060 protocol=udp src-address=10.8.8.20
add action=log chain=prerouting disabled=yes dst-address=VOIPPROXY log=yes \
    log-prefix=preToVOIPPROXY
add action=log chain=forward comment=onFOrward_ disabled=yes dst-address=\
    VOIPPROXY log=yes log-prefix=onFOrward_
add action=log chain=output comment=outputto_ disabled=yes dst-address=\
    VOIPPROXY log=yes log-prefix=outputTo_
add action=log chain=input comment=outoutLog_ disabled=yes dst-address=\
    VOIPPROXY log=yes log-prefix=inputTo_
add action=log chain=postrouting comment=to_Postrouting disabled=yes \
    dst-address=VOIPPROXY log=yes log-prefix=to_Postrouting protocol=\
    udp
add action=mark-packet chain=prerouting comment=toRDP dst-address-list=\
    RDPlist dst-port=3389 new-packet-mark=toRDPserver passthrough=yes \
    protocol=tcp
add action=mark-packet chain=prerouting dst-port=443 in-interface=ether1 \
    new-packet-mark=sstppm passthrough=yes protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat out-interface=ether1
add action=dst-nat chain=dstnat dst-port=5522 in-interface=ether1 protocol=\
    udp to-addresses=10.8.8.20
add action=dst-nat chain=dstnat dst-port=5060 in-interface=ether1 log-prefix=\
    SIP protocol=udp to-addresses=10.8.8.20 to-ports=5060
add action=dst-nat chain=dstnat dst-port=5061 in-interface=ether1 log-prefix=\
    SIP protocol=udp to-addresses=10.8.8.20
add action=dst-nat chain=dstnat dst-port=8100-8300 in-interface=ether1 \
    log-prefix=RTP protocol=udp to-addresses=10.8.8.20 to-ports=8100-8300
add action=dst-nat chain=dstnat comment=10000-20000 dst-port=10000-20000 \
    in-interface=ether1 protocol=udp to-addresses=10.8.8.20
/ip firewall raw
add action=notrack chain=prerouting dst-address=10.13.13.0/24 src-address=\
    10.8.8.0/24
add action=notrack chain=prerouting dst-address=10.8.8.0/24 src-address=\
    10.13.13.0/24
add action=log chain=prerouting comment=preroutingfrom10.8.8.20 disabled=\
    yes log=yes protocol=udp src-address=10.8.8.20
add action=log chain=prerouting comment=preroutingfromVOIPPROXY disabled=\
    yes log=yes log-prefix=preroutingfromVOIPPROXY protocol=udp \
    src-address=VOIPPROXY
add action=log chain=prerouting disabled=yes log=yes log-prefix=\
    preroutingfrom_ src-address=_
/ip firewall service-port
set h323 disabled=yes
set sip disabled=yes
/ip ipsec peer
add address=VPNGW/32 dh-group=modp1024 enc-algorithm=aes-256,aes-128 \
    exchange-mode=ike2
/ip ipsec policy
add comment="ipsec to _" dst-address=10.13.13.0/24 sa-dst-address=\
    VPNGW sa-src-address=WANIP250 src-address=10.8.8.0/24 \
    tunnel=yes
/ip route
add distance=1 gateway=WANIP249
add disabled=yes distance=1 dst-address=10.13.13.0/24 gateway=VPNGW
add disabled=yes distance=1 dst-address=10.9.9.0/24 gateway=10.8.8.1
/system clock
set time-zone-name=Europe
/system identity
set name=r1
/system routerboard mode-button
set enabled=no on-event=""
/tool mac-server
set allowed-interface-list=mactel
/tool mac-server mac-winbox
set allowed-interface-list=mac-winbox
/tool sniffer
set filter-interface=all filter-ip-address=VOIPPROXY/32 \
    filter-ip-protocol=udp

Re: Ipsec site to site nat dilemma

Posted: Wed Feb 21, 2018 10:13 pm
by sindy
OK, so sorry for not realizing from the previous conversation that the "action=accept connection-state=established" rule is irrelevant here as you have disabled connection-tracking of packets between sites A and B. But as you have no "action=drop" rule in "chain=output", I maintain my position that the accept rule in the output chain is not necessary ;-)

The bad news is that unless it is as simple as that the "action=accept chain=input protocol=tcp dst-port=22 ipsec-policy=in,ipsec ... " rule is really disabled as your "/export" suggests, I cannot see any reason at this end of the tunnel why the ssh access to the router from the remote side should not work. When you enable that rule and try to establish the ssh connection, can you see the packet counter at that rule to increment?

One off-topic bad news, relaying DHCP requests to a server via an IPsec tunnel doesn't work - or, more exactly, the relay works but the DHCP server sends the responses back to the relay's address using standard routing as it bypasses IPsec policy matching. I've talked with support about that and it does not seem to get fixed fast, if ever.

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 2:21 pm
by marwooj
The bad news is that unless it is as simple as that the "action=accept chain=input protocol=tcp dst-port=22 ipsec-policy=in,ipsec ... " rule is really disabled as your "/export" suggests, I cannot see any reason at this end of the tunnel why the ssh access to the router from the remote side should not work. When you enable that rule and try to establish the ssh connection, can you see the packet counter at that rule to increment?
Yes, when this rule is enabled I do see packet counter increasing.
One off-topic bad news, relaying DHCP requests to a server via an IPsec tunnel doesn't work - or, more exactly, the relay works but the DHCP server sends the responses back to the relay's address using standard routing as it bypasses IPsec policy matching. I've talked with support about that and it does not seem to get fixed fast, if ever.
Hi, I am rather not using this by purpose. I have dhcp servers on all sites.

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 3:15 pm
by sindy
The bad news is that unless it is as simple as that the "action=accept chain=input protocol=tcp dst-port=22 ipsec-policy=in,ipsec ... " rule is really disabled as your "/export" suggests, I cannot see any reason at this end of the tunnel why the ssh access to the router from the remote side should not work. When you enable that rule and try to establish the ssh connection, can you see the packet counter at that rule to increment?
Yes, when this rule is enabled I do see packet counter increasing.
Fine. Now enable your second rule, with src-port=22 etc., in the output chain, except that you set its action to "log". This allows to see the addresses of the response packets in the log if they exist. If they do, the issue is on the client side. If so, paste here the log item. If that rule's counters remain 0, it means the responses are not sent at all.
One off-topic bad news, relaying DHCP requests to a server via an IPsec tunnel doesn't work - or, more exactly, the relay works but the DHCP server sends the responses back to the relay's address using standard routing as it bypasses IPsec policy matching. I've talked with support about that and it does not seem to get fixed fast, if ever.
Hi, I am rather not using this by purpose. I have dhcp servers on all sites.
Well, I have seen in the configuration that you have the private IP of the remote router in the list of servers at the DHCP relay, so I've assumed that it is there on purpose.

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 7:00 pm
by marwooj
The Log:
Code: Select all
---
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (SYN,ACK), 10.8.8.1:22->10.13.13.2:49735, len 52 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (SYN,ACK), 10.8.8.1:22->10.13.13.2:49735, len 52 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, len 40 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, len 40 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 56 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 56 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 480 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 480 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:31 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:32 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:32 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:33 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:33 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:34 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:34 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:37 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:37 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:39 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:39 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 52 
17:14:44 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
17:14:44 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 496 
---

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 8:05 pm
by marwooj
And here is trace part from client:
Code: Select all
      1 0.000000000    10.13.13.2           10.8.8.1            SSHv2    82     Client: Protocol (SSH-2.0-PuTTY_Release_0.70)

Frame 1: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50091, Dst Port: 22, Seq: 1, Ack: 1, Len: 28
SSH Protocol

      2 9.612009800    10.13.13.2           10.8.8.1            TCP      54     50091 → 22 [RST, ACK, CWR] Seq=29 Ack=1 Win=0 Len=0

Frame 2: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50091, Dst Port: 22, Seq: 29, Ack: 1, Len: 0

      3 48.027885400   10.13.13.2           10.8.8.1            TCP      66     50095 → 22 [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 0, Len: 0

      4 48.040749200   10.8.8.1            10.13.13.2           TCP      66     22 → 50095 [SYN, ACK, ECN] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=32

Frame 4: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Microsof_b7:1c:47 (00:1d:d8:b7:1c:47), Dst: Microsof_CLI_MAC (CLI_MAC)
Internet Protocol Version 4, Src: 10.8.8.1, Dst: 10.13.13.2
Transmission Control Protocol, Src Port: 22, Dst Port: 50095, Seq: 0, Ack: 1, Len: 0

      5 48.040820100   10.13.13.2           10.8.8.1            TCP      54     50095 → 22 [ACK] Seq=1 Ack=1 Win=131328 Len=0

Frame 5: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 0

      6 48.041136500   10.13.13.2           10.8.8.1            SSHv2    82     Client: Protocol (SSH-2.0-PuTTY_Release_0.70)

Frame 6: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28
SSH Protocol

      7 48.349553500   10.13.13.2           10.8.8.1            TCP      82     [TCP Retransmission] 50095 → 22 [PSH, ACK] Seq=1 Ack=1 Win=131328 Len=28

Frame 7: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28

      8 48.958945400   10.13.13.2           10.8.8.1            TCP      82     [TCP Retransmission] 50095 → 22 [PSH, ACK] Seq=1 Ack=1 Win=131328 Len=28

Frame 8: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28

      9 50.160283200   10.13.13.2           10.8.8.1            TCP      82     [TCP Retransmission] 50095 → 22 [PSH, ACK] Seq=1 Ack=1 Win=131328 Len=28

Frame 9: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28

     10 52.566541500   10.13.13.2           10.8.8.1            TCP      82     [TCP Retransmission] 50095 → 22 [PSH, ACK] Seq=1 Ack=1 Win=131328 Len=28

Frame 10: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28

     11 57.368720200   10.13.13.2           10.8.8.1            TCP      82     [TCP Retransmission] 50095 → 22 [PSH, ACK] Seq=1 Ack=1 Win=131328 Len=28

Frame 11: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 1, Ack: 1, Len: 28

     12 66.981926800   10.13.13.2           10.8.8.1            TCP      54     50095 → 22 [RST, ACK, CWR] Seq=29 Ack=1 Win=0 Len=0

Frame 12: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: Microsof_CLI_MAC (CLI_MAC), Dst: Barconet_DST_MAC (DST_MAC:DST_MAC)
Internet Protocol Version 4, Src: 10.13.13.2, Dst: 10.8.8.1
Transmission Control Protocol, Src Port: 50095, Dst Port: 22, Seq: 29, Ack: 1, Len: 0

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 9:18 pm
by sindy
The Log:
Code: Select all
17:14:30 firewall,info SSH OUT output: in:(unknown 0) out:ether1, proto TCP (ACK,PSH), 10.8.8.1:22->10.13.13.2:49735, NAT (10.8.8.1:22->WANIP250:22)->10.13.13.2:49735, len 56
OK, I've got it. I've missed yesterday that the rules
Code: Select all
/ip firewall raw
add action=notrack chain=prerouting dst-address=10.13.13.0/24 src-address=\
    10.8.8.0/24
add action=notrack chain=prerouting dst-address=10.8.8.0/24 src-address=\
    10.13.13.0/24
only deal with forwarded packets, not with packets output by the router itself.

So you need another pair of rules:
Code: Select all
/ip firewall raw
add action=notrack chain=output dst-address=10.13.13.0/24 src-address=\
    10.8.8.0/24
add action=notrack chain=input dst-address=10.8.8.0/24 src-address=\
    10.13.13.0/24
Or you may replace the 10.8.8.0/24 by the individual (/32) address of the router, it does not matter.

Re: Ipsec site to site nat dilemma

Posted: Thu Feb 22, 2018 10:40 pm
by marwooj

So you need another pair of rules:
Code: Select all
/ip firewall raw
add action=notrack chain=output dst-address=10.13.13.0/24 src-address=\
    10.8.8.0/24
add action=notrack chain=input dst-address=10.8.8.0/24 src-address=\
    10.13.13.0/24
Or you may replace the 10.8.8.0/24 by the individual (/32) address of the router, it does not matter.
To understand this correctly I should add your, not replace mine?

Re: Ipsec site to site nat dilemma  [SOLVED]

Posted: Thu Feb 22, 2018 10:44 pm
by sindy

So you need another pair of rules:
Code: Select all
/ip firewall raw
add action=notrack chain=output dst-address=10.13.13.0/24 src-address=\
    10.8.8.0/24
add action=notrack chain=input dst-address=10.8.8.0/24 src-address=\
    10.13.13.0/24
Or you may replace the 10.8.8.0/24 by the individual (/32) address of the router, it does not matter.
To understand this correctly I should add your, not replace mine?
Yes, sorry for ambiguous expression. Your rules handle packets forwarded by the router between the other end of the IPsec tunnel and other devices on its local LAN, my rules handle packets received and sent by your router itself.

Re: Ipsec site to site nat dilemma

Posted: Fri Feb 23, 2018 7:12 pm
by marwooj

Yes, sorry for ambiguous expression. Your rules handle packets forwarded by the router between the other end of the IPsec tunnel and other devices on its local LAN, my rules handle packets received and sent by your router itself.

Great !!! It works !!! Moving on to next issue :-)

Re: Ipsec site to site nat dilemma

Posted: Sat Feb 24, 2018 8:15 am
by nichky
and what a differences between those two ? accept and notrack.

What differences did you find?

Thanks

Re: Ipsec site to site nat dilemma

Posted: Sat Feb 24, 2018 10:26 am
by sindy
and what a differences between those two ? accept and notrack.

What differences did you find?

Thanks
@nichky, this question cannot be replied without providing a lot of context.
  • no-track is an action which only makes sense in the mangle table and you can look at it as if it marks the packet to be ignored by the connection tracking engine which is one of next stages of packet processing in the firewall
  • accept is an action which can be used in any chain of any firewall table and it lets the packet proceed to the following stage of processing without checking any following rules in the chain of the current stage
The tunnelling mode of IPsec chooses packets to be tunnelled by matching them against an "IPsec policy", which is one of the last stages of packet processing before they are sent out via an interface. The ultimate goal of using some extra rules for packets which we want to be handled by the IPsec policy is to prevent anything which would make them invisible for the policy. This could be:
  • src-nat handling, which changes the source address of the packet, so the IPsec policy would not match the changed address,
  • fasttrack handling, which skips, among other packet processing stages, also the matching against the IPsec policy.
Both src-nat and fasttrack can only happen if the packets are connection tracked. So by using a no-track rule in mangle table (for the packets which should be matched by the IPsec policy later on), you prevent both. By using an accept rule in the nat table for these packets, before any src-nat rule, you prevent them from being src-nat'ed as by accepting them you don't allow them to reach that src-nat rule.

So if you have the no-track rule in the mangle table in place, you do not need the accept rule in the nat table. If you do not have the no-track rule, you can use connection tracking as usually (sometimes full transparency between the LANs at the ends of the tunnel is not what you want so you need a stateful firewall which requires connection tracking to work), but you have to use the "accept before src-nat" rule, and if you use fasttracking, you need yet another accept rule, this time in the filter table, to prevent the packets-to-be tunnelled and also packets-which-just-came-through-the-tunnel from hitting the "fasttrack-connection" rule later in that chain.

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 10:20 am
by marwooj
Hi, just as a addition I would like to ask if it is reasonable to VoIP into s2s tunnel?

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 11:00 am
by sindy
Hi, just as a addition I would like to ask if it is reasonable to VoIP into s2s tunnel?
There are several important aspects to consider.
  1. the quality and stability of the network path between the sites. I don't know your country and ISP specifics so it may vary between "no need to think about it" to "forget it immediately".
  2. the total volume of RTP traffic (say, concurrent calls at peak time) vs the ciphering throughput. If we talk about units of concurrent calls, software encryption will do; if we talk about hundreds, you may need a router model with hardware encryption (like hEX - RB750Gr3 or hAP AC2 - RBD52G-5HacD2HnD). The hardware encryption only works for particular algorithms and to date only for IPsec.
  3. the QoS (traffic prioritization). You need to give VoIP an absolute priority over any other traffic on the uplink and implement some download throttling techniques. [EDIT]To do that in conjunction with encryption and encapsulation, you have to set DSCP marks of the packets to be tunnelled as the DSCP mark is the only property of the packet which survives the encapsulation and encryption in tunnelling mode. All the rest (source and destination addresses and ports, protocol types) is encapsulated and encrypted and thus invisible for the firewall rules. But this works only in upload direction; in the download direction, you may need to throttle TCP traffic by shaping it on the way to local clients to leave enough space for the VPN transport traffic, and do the same for the TCP part of the VPN traffic to reserve enough space for the VoIP traffic. May because it is possible that the DSCP marking of the IPsec transport packets from the remote site will survive the transit through the internet, so you will still know which of the incoming transport packets to throttle and which not, but you have to check first.[/EDIT] I've never tried to do that yet. Also, don't forget that traffic prioritization (queues) is incompatible with fastpath processing so if you use fastpath and fasttrack now, you'll be surprised by the overall performance drop.
So it is fine to use VPN only to extend a private VoIP network, but if you want to mix normal traffic like web browsing, file transfers, client/server applications atop TCP, or even some other real-time applications, get ready for a challenge.

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 7:13 pm
by marwooj
VoIP and QoS is already a challenge. I have been struggling with this for months now.

Perhaps you know answers to my questions about Option 2 QoS from this topic?

viewtopic.php?f=13&t=73214&p=646581&hilit=voip#p646581
viewtopic.php?f=13&t=73214&p=646584&hilit=voip#p646584

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 7:24 pm
by CZFan
VoIP and QoS is already a challenge. I have been struggling with this for months now.

Perhaps you know answers to my questions about Option 2 QoS from this topic?

viewtopic.php?f=13&t=73214&p=646581&hilit=voip#p646581
viewtopic.php?f=13&t=73214&p=646584&hilit=voip#p646584

Perhaps you should start a "new" topic?

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 10:21 pm
by sindy
Please check my edit in #23. Sorry for misleading you about the need to prioritize all IPsec transport packets in upload direction, there actually is a way to deliver the information about required priority through the encapsulation and encryption machinery.

Re: Ipsec site to site nat dilemma

Posted: Sun Mar 11, 2018 11:57 pm
by sindy
I've just checked on my test IPsec link spanning some 1000 km crow line - funny enough, the upper three bits of the DSCP field get set to zero in transit but the lower three bits survive. So you may have to be creative when marking the traffic, the goal being to get a distinctive value on reception. So a single surviving bit is enough.
All times are UTC+03:00
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/