OP is NATing properly from what I can see. tun0 interface belongs to the wan zone in firewall.
1 Like
Hey, couldn'd send yesterday because of new-user-restrictions
that
iptables -t nat -A PREROUTING -i tun0 -p udp --dport 2000 -j DNAT --to-dest 192.168.1.156
does the trick.
The Phone was able do contact the tftp-server
meanwhile i extended this to
iptables -t nat -A PREROUTING -i tun0 -p udp -s 192.168.10.4 -j DNAT --to 192.168.1.156
But i still has one issue, i cant hear anything in the IP-Phone. Sending works, signalling works, call initiation works, call recieving works. But no incoming sound 
One error in tcpdump comes up: 11:19:44.844734 IP 192.168.10.4 > 192.168.1.156: ICMP 192.168.10.4 udp port 27627 unreachable, length 80 but exactly one time
Thanks so far for your excellent support
Chris
1 Like
You'll need to allow the ports that the phone requires. Usually phones are able to keep sending keepalives to keep the ports open on the firewall, but it seems that this is not the case here.
If you trust the corporate network, put the VPN tunnel in the lan firewall zone, which will let corporate traffic effectively bypass the OpenWrt firewall. Be sure that the default forwarding within the lan zone is enabled.
If you aren't willing to trust everything on the corporate network it's going to get more complicated. This would call for a separate zone for the VPN because you are going to allow some things you wouldn't want to expose on the Internet, which will happen if you share a zone between VPN and WAN.
It may make more sense to set up rules on an IP basis instead of ports. For example allow in all ports to / from the PBX. The phone should only need the PBX and the TFTP server.
OP most likely needs masquerading to the vpn, as I don't think the OpenVPN server will accept routes from clients. So he'll have to DNAT if some port needs to be opened from VPN to lan.
I think i'm stuck here again.
The crazy thing is that everything but hearing does it now.
I am not able to see any errors in tcpdump
nat POSTROUTING is set to masquerady,
nat PREROUTING incoming udp and tcp is DNATed to OP
I still have no clue
tun0 is now in LAN zone, no change
Keep it in wan zone where masquerade is taking place. Otherwise the server won't know where to return the packets.
Post the iptables rules you have applied.
1 Like
okay, i switched it back to wan zone
/etc/firewall.user says
iptables -t nat -A PREROUTING -i tun0 -p udp -s 192.168.10.4 -j DNAT --to 192.168.1.156
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
complete firewall
root@OpenWrt:~# iptables-save -c
# Generated by iptables-save v1.8.3 on Sat May 2 20:58:53 2020
*nat
:PREROUTING ACCEPT [213:26133]
:INPUT ACCEPT [25:2208]
:OUTPUT ACCEPT [75:5664]
:POSTROUTING ACCEPT [2:872]
:postrouting_lan_rule - [0:0]
:postrouting_rule - [0:0]
:postrouting_wan_rule - [0:0]
:prerouting_lan_rule - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan_rule - [0:0]
:zone_lan_postrouting - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_postrouting - [0:0]
:zone_wan_prerouting - [0:0]
[1:544] -A PREROUTING -s 192.168.10.4/32 -i tun0 -p udp -j DNAT --to-destination 192.168.1.156
[213:26133] -A PREROUTING -m comment --comment "!fw3: Custom prerouting rule chain" -j prerouting_rule
[157:19302] -A PREROUTING -i br-lan -m comment --comment "!fw3" -j zone_lan_prerouting
[6:531] -A PREROUTING -i tun0 -m comment --comment "!fw3" -j zone_wan_prerouting
[0:0] -A PREROUTING -i eth0.2 -m comment --comment "!fw3" -j zone_wan_prerouting
[50:6300] -A PREROUTING -i wlan1 -m comment --comment "!fw3" -j zone_wan_prerouting
[9:1207] -A POSTROUTING -o tun0 -j MASQUERADE
[114:10468] -A POSTROUTING -m comment --comment "!fw3: Custom postrouting rule chain" -j postrouting_rule
[2:872] -A POSTROUTING -o br-lan -m comment --comment "!fw3" -j zone_lan_postrouting
[0:0] -A POSTROUTING -o tun0 -m comment --comment "!fw3" -j zone_wan_postrouting
[0:0] -A POSTROUTING -o eth0.2 -m comment --comment "!fw3" -j zone_wan_postrouting
[112:9596] -A POSTROUTING -o wlan1 -m comment --comment "!fw3" -j zone_wan_postrouting
[2:872] -A zone_lan_postrouting -m comment --comment "!fw3: Custom lan postrouting rule chain" -j postrouting_lan_rule
[157:19302] -A zone_lan_prerouting -m comment --comment "!fw3: Custom lan prerouting rule chain" -j prerouting_lan_rule
[112:9596] -A zone_wan_postrouting -m comment --comment "!fw3: Custom wan postrouting rule chain" -j postrouting_wan_rule
[0:0] -A zone_wan_postrouting -s 192.168.1.156/32 -d 192.168.10.4/32 -m comment --comment "!fw3: @nat[0]" -j MASQUERADE
[112:9596] -A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE
[56:6831] -A zone_wan_prerouting -m comment --comment "!fw3: Custom wan prerouting rule chain" -j prerouting_wan_rule
COMMIT
# Completed on Sat May 2 20:58:53 2020
# Generated by iptables-save v1.8.3 on Sat May 2 20:58:53 2020
*mangle
:PREROUTING ACCEPT [980:134211]
:INPUT ACCEPT [272:36306]
:FORWARD ACCEPT [567:79447]
:OUTPUT ACCEPT [532:101388]
:POSTROUTING ACCEPT [1004:168255]
[3:180] -A FORWARD -o tun0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
[0:0] -A FORWARD -o eth0.2 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
[32:1920] -A FORWARD -o wlan1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment --comment "!fw3: Zone wan MTU fixing" -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Sat May 2 20:58:53 2020
# Generated by iptables-save v1.8.3 on Sat May 2 20:58:53 2020
*filter
:INPUT ACCEPT [9:583]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:forwarding_lan_rule - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan_rule - [0:0]
:input_lan_rule - [0:0]
:input_rule - [0:0]
:input_wan_rule - [0:0]
:output_lan_rule - [0:0]
:output_rule - [0:0]
:output_wan_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan_dest_ACCEPT - [0:0]
:zone_lan_forward - [0:0]
:zone_lan_input - [0:0]
:zone_lan_output - [0:0]
:zone_lan_src_ACCEPT - [0:0]
:zone_wan_dest_ACCEPT - [0:0]
:zone_wan_forward - [0:0]
:zone_wan_input - [0:0]
:zone_wan_output - [0:0]
:zone_wan_src_ACCEPT - [0:0]
[0:0] -A INPUT -i lo -m comment --comment "!fw3" -j ACCEPT
[275:36462] -A INPUT -m comment --comment "!fw3: Custom input rule chain" -j input_rule
[234:32466] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
[1:60] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "!fw3" -j syn_flood
[12:1017] -A INPUT -i br-lan -m comment --comment "!fw3" -j zone_lan_input
[11:858] -A INPUT -i tun0 -m comment --comment "!fw3" -j zone_wan_input
[0:0] -A INPUT -i eth0.2 -m comment --comment "!fw3" -j zone_wan_input
[18:2121] -A INPUT -i wlan1 -m comment --comment "!fw3" -j zone_wan_input
[567:79447] -A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain" -j forwarding_rule
[168:9090] -A FORWARD -m comment --comment "!fw3: Traffic offloading" -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
[168:9090] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
[396:68661] -A FORWARD -i br-lan -m comment --comment "!fw3" -j zone_lan_forward
[1:544] -A FORWARD -i tun0 -m comment --comment "!fw3" -j zone_wan_forward
[0:0] -A FORWARD -i eth0.2 -m comment --comment "!fw3" -j zone_wan_forward
[2:1152] -A FORWARD -i wlan1 -m comment --comment "!fw3" -j zone_wan_forward
[2:1152] -A OUTPUT -o lo -m comment --comment "!fw3" -j ACCEPT
[533:100812] -A OUTPUT -m comment --comment "!fw3: Custom output rule chain" -j output_rule
[448:94457] -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "!fw3" -j ACCEPT
[2:659] -A OUTPUT -o br-lan -m comment --comment "!fw3" -j zone_lan_output
[5:200] -A OUTPUT -o tun0 -m comment --comment "!fw3" -j zone_wan_output
[0:0] -A OUTPUT -o eth0.2 -m comment --comment "!fw3" -j zone_wan_output
[78:5496] -A OUTPUT -o wlan1 -m comment --comment "!fw3" -j zone_wan_output
[0:0] -A reject -p tcp -m comment --comment "!fw3" -j REJECT --reject-with tcp-reset
[0:0] -A reject -m comment --comment "!fw3" -j REJECT --reject-with icmp-port-unreachable
[1:60] -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN
[0:0] -A syn_flood -m comment --comment "!fw3" -j DROP
[2:659] -A zone_lan_dest_ACCEPT -o br-lan -m comment --comment "!fw3" -j ACCEPT
[396:68661] -A zone_lan_forward -m comment --comment "!fw3: Custom lan forwarding rule chain" -j forwarding_lan_rule
[396:68661] -A zone_lan_forward -m comment --comment "!fw3: Zone lan to wan forwarding policy" -j zone_wan_dest_ACCEPT
[0:0] -A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
[0:0] -A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
[12:1017] -A zone_lan_input -m comment --comment "!fw3: Custom lan input rule chain" -j input_lan_rule
[0:0] -A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
[12:1017] -A zone_lan_input -m comment --comment "!fw3" -j zone_lan_src_ACCEPT
[2:659] -A zone_lan_output -m comment --comment "!fw3: Custom lan output rule chain" -j output_lan_rule
[2:659] -A zone_lan_output -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT
[12:1017] -A zone_lan_src_ACCEPT -i br-lan -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
[53:6719] -A zone_wan_dest_ACCEPT -o tun0 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
[274:53333] -A zone_wan_dest_ACCEPT -o tun0 -m comment --comment "!fw3" -j ACCEPT
[0:0] -A zone_wan_dest_ACCEPT -o eth0.2 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
[0:0] -A zone_wan_dest_ACCEPT -o eth0.2 -m comment --comment "!fw3" -j ACCEPT
[41:5285] -A zone_wan_dest_ACCEPT -o wlan1 -m conntrack --ctstate INVALID -m comment --comment "!fw3: Prevent NAT leakage" -j DROP
[113:10172] -A zone_wan_dest_ACCEPT -o wlan1 -m comment --comment "!fw3" -j ACCEPT
[3:1696] -A zone_wan_forward -m comment --comment "!fw3: Custom wan forwarding rule chain" -j forwarding_wan_rule
[0:0] -A zone_wan_forward -p esp -m comment --comment "!fw3: Allow-IPSec-ESP" -j zone_lan_dest_ACCEPT
[0:0] -A zone_wan_forward -p udp -m udp --dport 500 -m comment --comment "!fw3: Allow-ISAKMP" -j zone_lan_dest_ACCEPT
[1:544] -A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port forwards" -j ACCEPT
[2:1152] -A zone_wan_forward -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
[29:2979] -A zone_wan_input -m comment --comment "!fw3: Custom wan input rule chain" -j input_wan_rule
[0:0] -A zone_wan_input -p udp -m udp --dport 68 -m comment --comment "!fw3: Allow-DHCP-Renew" -j ACCEPT
[0:0] -A zone_wan_input -p icmp -m icmp --icmp-type 8 -m comment --comment "!fw3: Allow-Ping" -j ACCEPT
[2:72] -A zone_wan_input -p igmp -m comment --comment "!fw3: Allow-IGMP" -j ACCEPT
[0:0] -A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "!fw3: Accept port redirections" -j ACCEPT
[27:2907] -A zone_wan_input -m comment --comment "!fw3" -j zone_wan_src_ACCEPT
[83:5696] -A zone_wan_output -m comment --comment "!fw3: Custom wan output rule chain" -j output_wan_rule
[83:5696] -A zone_wan_output -m comment --comment "!fw3" -j zone_wan_dest_ACCEPT
[6:531] -A zone_wan_src_ACCEPT -i tun0 -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
[0:0] -A zone_wan_src_ACCEPT -i eth0.2 -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
[12:1793] -A zone_wan_src_ACCEPT -i wlan1 -m conntrack --ctstate NEW,UNTRACKED -m comment --comment "!fw3" -j ACCEPT
COMMIT
# Completed on Sat May 2 20:58:53 2020
The masquerade is already applied.
The DNAT has one hit, I would expect more.
I discussed it earlier with a voice expert colleague of mine. Everything working but not hearing back could be asymmetry in routing (some firewall is dropping invalid packets) or maybe you need to open more ports from other IPs, not only 192.168.10.4.
In any case you can check the sip logs in both phone and server, as well as a wireshark/tcpdump on the vpnserver to verify if packets are dropped before or after it.
Good morning,
what I can see in wireshark is that I'm still getting a destination unreachable error.
I'm not very good in reading this.
This port unreachable icmp is sent from 10.4 to your OpenWrt, most likely because the ip phone tried to access some closed port.
Hmm okay, so it has nothing to do with NAT or so?
Accourding to our Service-Technician for the PBX, there are no SIP Logs
tcpdump has no other error messages present
Without logs or errors it's hard to troubleshoot any further.
Last suggestion to rule out firewall issues:
- Delete
list device tun0from wan firewall zone - Add
list device tun0in lan firewall zone - Add
option masq '1'and
list masq_dest 192.168.10.0/24
list masq_dest 192.168.20.0/24
list masq_dest 192.168.30.0/24
list masq_dest 192.168.40.0/24
in lan firewall zone.
Did this all, but no change.
Is it simply possible that this comes through a hardware-defect?
I tried Handset, Speaker and Jabra Headset, can't hear anything
nmap or traceroute from your router might shed some light... as would mapping out all the hosts involved in the routing, load balancing or firewalling at the business end ( simple diagram )...
several signs are pointing towards some step / steps in the chain at that end which are unknown and problematic.
I have sucessfully running a softphone on windows tablet with openvpn
It is standing right beneath me.
Technically this is not different from the set-up i try to implement using the openWRT router.
so no company firewalls or anything else is blocking here.
It is "only" a nat or dnat issue on openwrt router, I suggest.
But my capabilities seem to be too limited here.
Thought i knew firewalling better -_-
You should try the phone in a different network environment to verify that.
So, today i was in the office. My phone worked without any problems.
Back here, same as yesterday... Phone connects but no sound to be heard.
I'm totally perplexed
I just found something interesting on the VPN Server.
RwRwRwrWrWrW[...]RwRTue May 5 22:03:56 2020 us=789602 openWRTClt/<Public IP-Address>:50834 MULTI: bad source address from client [192.168.1.156], packet dropped
RTue May 5 22:03:56 2020 us=790380 openWRTClt/<Public IP-Address>:50834 MULTI: bad source address from client [192.168.1.156], packet dropped
Rw[...]dress from client [192.168.1.156], packet dropped
Rw[...]WRTue May 5 22:04:32 2020 us=785548 openWRTClt/<Public IP-Address>:50834 MULTI: bad source address from client [192.168.1.156], packet dropped
RwRw[...]WRRTue May 5 22:04:44 2020 us=784743 openWRTClt/<Public IP-Address>:50834 MULTI: bad source address from client [192.168.1.156], packet dropped
RwRw[...]Rw^C
It seems that my Phone (the client 192.168.1.156) tunnels through VPN with its origin IP
So why does iptables masquerade only some packets and some not?